You are on page 1of 21

Administration Rseau-systme SNMPv1, SNMPv2, SNMPv3 et HTTP

Yves.Bertsch@lapp.in2p3.fr Frederic.Stmarcel@lapp.in2p3.fr

Rsum : Cet article dveloppe les solutions actuelles de ladministration rseau, en insistant particulirement sur SNMP. Aprs un rappel des dfauts de jeunesse de SNMP, on exposera SNMPv3, protocole mature, muni de tous les outils de scurit requis en milieu ouvert. SNMPv3 sera sans doute incontournable dans la gestion des grands rseaux, exigeant efficacit et scurit. Au dessous dune certaine taille de rseaux, des solutions trs diversifies, souvent orientes objet, plus ou moins intgres dans le WEB seront offertes lutilisateur. Ces approches, qui privilgient lintelligence et linitiative dans lappareillage se diffrencient de lapproche scalaire classique de SNMP. Larticle cite quelques unes de ces techniques de gestion alternatives et parfois complmentaires SNMP.

Introduction
SNMP sinscrit dans la marche vers les standards, approche ncessaire dans un monde de constructeurs diversifis. La dmarche pragmatique de TCP/IP a longtemps t oppose la rputation de complexit et de lourdeur de mise en uvre des produits de lOSI. LIETF et OSI ont men terme une administration rseaux dont les cahiers des charges taient proches, mais avec des techniques diffrentes. La place prpondrante de SNMP est elle dfinitive ? La complexit de SNMPv3 ne rappelle t elle pas les dfauts des produits OSI ? Deux ans bientt aprs le bouclage des dfinitions de lIETF sur SNMPv3, quen est il des produits SNMPv3 ? Ce protocole rpond-il aujourdhui rellement une demande ? Lmergence des techniques orientes WEB ne menace-t-elle pas lapproche classique de ladministration rseau ? Que faut-il attendre de la puissance logicielle implante dans les quipements ? Autant de questions qui nous interpellent, la ncessit de prendre en compte ladministration rseaux (et systme) ntant plus dmontrer. Nous essayerons de mettre en vidence les points importants de lvolution des techniques dadministration SNMP en illustrant avec un aperu des rsultats obtenus sur des agents cisco3640 SNMPv1/v2c et v3 (rares en quipements). Ces valuations ont t menes avec des gestionnaires SNMPv3 sur LINUX et NT . Des agents SNMPv3 tournant sur LINUX et NT ont t galement tests. Les rflexions en cours actuellement sur les volutions de SNMP seront abordes. Les techniques alternatives ou complmentaires SNMP, le plus souvent base de gestion par le WEB, seront succinctement prsentes ; le sujet justifierait lui seul une prsentation complte. Les bases de SNMP sont supposes connues et on insistera sur lapport de SNMPv3. Toutefois des complments sur SNMP ainsi que des rsultats plus dtaills de dveloppements et tests sont rappels en ANNEXE et sont disponibles sur les sites WEB de JRES et du LAPP. Lemploi de sigles ou dexpressions anglaises (plus compactes) pouvaient difficilement faire lobjet dune traduction en pied de page. On trouvera un glossaire la fin de larticle.

1. Historique, buts et bilan de SNMPv1


Lorigine de SNMP remonte la fin des annes 80 et concide avec lacclration de la croissance mondiale de TCP/IP. SNMP, sous lappellation SGMP (G pour Gateway), est dabord une rponse la gestion des routeurs IP qui doivent couler un trafic en forte expansion. A cette poque, la concurrence entre OSI et TCP/IP est encore vive et cette situation explique en partie les bases sur lesquelles les concepteurs de SNMP vont sappuyer. Il sagit de laisser ouverte une convergence possible avec CMIP/CMIS, protocole dadministration de OSI qui est alors en dveloppement. Ainsi les choix de ASN-1 pour la syntaxe abstraite (criture des MIBs) et BER pour lencodage sur le rseau, lintgration dans lespace de nommage de lISO pour la classification des variables qui allaient constituer la MIB SNMP illustrent cette dmarche. Lapproche pragmatique de lIETF a conduit rapidement un protocole volontairement simpliste dont le domaine dapplication a trs vite dbord du cadre de dpart (les routeurs) pour sintresser lensemble des constituants du rseau, puis du systme par la suite. Laffirmation de lInternet comme standard de fait a consacr le divorce avec OSI (chec de CMOT : CMIP over TCP) et permet lIETF de mettre en chantier la seconde mouture de SNMP, appele amliorer les insuffisances du cadre dadministration et introduire les outils indispensables de scurisation (authentification

621

Technologies rseaux avances

et cryptage). Si la ncessit de se doter dun outil de contrle de la croissance de lInternet a t un lment dterminant dans le dmarrage de SNMP, la motivation collective sengager dans la voie des standards a galement beaucoup compt. Une dcision importante fut dallouer aux constructeurs une branche prive dans lespace de nommage, leur permettant de traduire dans le cadre du standard toute leur spcificit. La MIB gnraliste de dpart (MIB-I, puis MIB-II) tait en effet trs pauvre et les particularits des quipements rseaux ntaient pas encore dveloppes dans la MIB standard. Avant de dvelopper SNMPv3, sujet principal ici, il est utile de faire un bilan de SNMP ce jour, bilan en fait de SNMPv1 et SNMPv2c (qui est en gros SNMPv1 avec les amliorations du cadre dadministration SMIv2, qui sera voqu plus loin). 1.1 Rappel SNMPv1

Figure 1 Contrairement CMIP (peu diffus) qui a adopt dentre une approche oriente objet, SNMP a choisi une approche scalaire. La complexit est concentre dans le gestionnaire, lagent se contentant principalement de rpondre aux requtes du gestionnaire . Lagent peut cependant aussi envoyer spontanment des alarmes ou alertes (TRAP). Ce schma rpond aux possibilits de lpoque , la puissance CPU de lagent tant lorigine limite. 1.2 Lespace de nommage Avant SNMP, les quipements rseau (hubs, ponts) possdaient dj un mcanisme de dialogue (rs232, telnet) des fins dadministration. La nature des donnes explores, bien que similaires pour les paramtres courants, dpendaient de limplmentation des constructeurs. En particulier, chaque constructeur grait sa propre classification des variables juges utiles, selon sa perception. Le corollaire de cette situation tait videmment que la fonction administration des quipements manait du constructeur avec tous les inconvnients que cela implique. Avec SNMP, toute donne accde dans un quipement (agent) correspond une variable dfinie et rpertorie par les organismes de standardisation (IETF, IANA ). Pour SNMP, le choix stratgique de lespace de nommage de lISO commandait dadopter le langage de dfinition des variables (ASN.1), lencodage sur le rseau (BER). Par souci de simplification, SNMP sest limit un sous ensemble de ces mcanismes. La structuration arborescente de lespace de nommage est classique. On parle de base de donnes virtuelle . Un quipement est accessible en tant que nud IP (processus agent), lequel autorise (sous contrle) laccs aux paramtres le dcrivant par une MIB. Ces objets, administrativement grs, sont nomms en donnant le parcours complet depuis la racine : 1.3.6.1.2.1.x.y.pour les variables de la MIB standard, 1.3.6.1.4.1.x.y pour les variables MIB constructeurs, x tant No attribu au constructeur 1.3.6.1.6.3.x.y pour les variables traduisant larchitecture SNMPv3

622

Technologies rseaux avances

Figure 2 1.3 Aspects du langage ASN.1 (Abstract Syntax Notation Number 1) et BER (Basic Encoding Rules) La comprhension de ASN.1 est incontournable pour quiconque doit travailler dans lenvironnement SNMP. Quil sagisse dapprofondir la fonction de telle variable dune MIB standard ou prive, de modifier une partie de MIB qui ne passe pas la compilation, de consulter une RFC sur le protocole ou la cadre dadministration, la connaissance des mcanismes de ce langage est indispensable. Il sagit dun langage, usage de lecture humaine. Pas dinitialisation de variables, pas de dimensionnement de tableaux, tout au plus des restrictions du champ de valeurs possibles. ASN.1 doit tre transpos en langage excutable (C ou assembleur) pour intgrer le binaire que constitue lagent (transparent lutilisateur). On retrouve partiellement les caractristiques de lapproche objet : une variable (de la MIB) est cre par invocation dune macro (terme impropre parfois appele construct , Perkins [12]. La puissance mais aussi le danger de ASN.1 (on peut indfiniment enrichir la grammaire) est bien souligne par T.Marshall ROSE [ 9 ]. SMIv1 et SMIv2 (Structure of Management Information : Cadre dadministration) Ce quon appelle SMIv1, cest les dfinitions du langage ASN.1 adapt SNMP, cest dire les types primitifs universels ISO simples (INTEGER, OCTET STRING) et construits (SEQUENCE : concatnation de types simples), ainsi que les types spcialement crs pour SNMP (ipAddress, Counter). Cest aussi les rgles de grammaire (MACRO) pour crer les objets qui vont peupler les MIBs. La simplification un peu excessive et le manque de prvision (compteurs limits 32 bit) a demand une nouvelle version appele SMIv2. La manipulation des tables est un peu droutante, assez lourde et inlgante dans SNMPv1. Des amliorations sensibles ont t apportes dans SNMPv2, mais les tables restent un point controvers dans SNMP (pas de commande directe pour obtenir le contenu dune table). Quelques prcisions sont apportes en ANNEXE. 1.4 Bilan de SNMPv1/v2C : SNMPv2 en version initiale (1993) devait corriger dune part les imperfections de SNMPv1 (SMIv1 trop triqu) et surtout apporter le volet scurit. En effet dans SNMPv1, la scurit repose sur la connaissance mutuelle (entre agent et gestionnaire) dune chane de caractre (la communaut) insre dans le message. Cette communaut ntant pas crypte, elle est interceptable sur le rseau. Le premier point a t atteint (SMIv2), mais le volet scurit na pas rencontr le consensus. Ce standard, SNMPv2p (p pour party based) reposait sur un dialogue entre entits appeles party , et devait dboucher sur un nouveau format de message (qui na pas abouti). Pour ne pas perdre le bnfice des avances du SMIv2, on a gard lenveloppe du message SNMPv1 (communaut) et utilis le SMIv2 dans les MIB; lenrichissement du protocole (nouvelles Units de protocole : PDU) a t galement retenu. Cest ce quon appelle SNMPv2c (C pour community), class exprimental . On fera donc un bilan global SNMPv1/v2C.

623

Technologies rseaux avances

1.4.1 Points ngatifs Reproche principal : manque de scurit (communaut circule en clair sur le rseau) Manipulation des tableaux lourde et inefficace (sensiblement amliore par le SMIv2). Protocole inefficace (pas de transfert de masse dans V1), corrig dans V2c (PDU getbulk) Alertes (TRAP) non acquittes dans SNMPv1, corrig dans v2C avec la PDU de notification INFORM (acquitte) en plus de TRAP(non acquitt) Entiers limits 32bit (V1), insuffisant pour les compteurs (corrig dans SMIv2 avec compteur 64 bit) Pas de relle possibilit de limitations slectives daccs la MIB de lagent Nommage des variables trop long (tout le parcours 1.3.6.1.2.1.., surtout pour les lments de tableaux), aggrav par lencodage BER. Impact perceptible sur la bande passante du rseau, en particulier en liaison gographique de faible dbit (64 Kbit). Mcanisme atomique de V1 (une erreur dans la requte annule toute la requte), corrig par V2 par le mcanisme des exceptions (donne le maximum de rponses en cas derreur sur une variable) Manque de coordination entre gestionnaires , la MIB M2M (manager to manager) rglementait ce type dchange dans snmpv2 scuris (1993) qui na pas t retenu.

1.4.2 Points positifs : Standard bien accept dans lensemble, tous les constructeurs limplmentent dans leur quipement, les MIB sont crites systmatiquement en SMIv2 ) Couverture vaste des MIB dcrivant les quipements les plus divers du rseau Une certaine compatibilit dapproche avec le monde OSI (ASN.1, espace de nommage) Grand choix de gestionnaires (du petit browser la puissante plate-forme HPOV) Le SMIv2 apporte des fonctionnalits nouvelles dans la manipulation des tables AUGMENT : permet de prolonger (ajout de colonnes) une table existante Type ROWSTATUS, addition/suppression dynamique de ranges dans les tables. Cette dernire fonctionnalit est utilise de faon systmatique dans les tables dcrivant les sous systmes du nouveau cadre dadministration de SNMPv3. On constate quun certain nombre dimperfections ont pu tre corriges par ladoption du SMIv2 avec SNMPv2C, version dattente faute de mieux, qui laissait de cot le volet scurit. 1.5 Volet scurit report Le rejet du volet scurit (1993) SNMPv2p (P pour party based, lentit communicante SNMP sappelant party ), a tenu essentiellement un mcanisme de manipulation de cls (authentification et cryptage) impraticable. Deux standards concurrents allaient alors saffronter pendant deux annes jusqu dbut 97, SNMPv2U et SNMPv2*. Ces deux standards avaient en fait dj adopt le mcanisme de cls localises qui sera retenu dans SNMPv3. Il tait donc envisageable de faire une synthse de ces deux standards, une fois les esprits calms, condition imprative pour sauver le protocole SNMP.

2. Version SNMPv3 Aboutissement actuel (achev fin 1999, dploiement en cours)


Le groupe de travail (1997) charg de concilier les approches concurrentes, a redfini compltement la structure du cadre dadministration tout en posant en principe lacquis de lessentiel du SMIv2 et lenrichissement du dialogue entre entits SNMP ( nouvelles units de donnes de protocoles, PDU Getbulk, Inform, Report). 2.1 Cahier des charges de SNMPv3 1) Introduire les outils de scurisation (authentification, cryptage, contrle du timing). Dfi : satisfaire la fois les besoins en administration lourde (grands rseaux, scurit, gestion distance scurise, y compris des cls ) et les besoins simples dadministration dun petit rseau local sans subir une lourdeur inutile. 2) Rendre possible une volution spare des diffrentes composantes de la nouvelle architecture. La nouvelle approche est ncessairement modulaire, afin de satisfaire cet objectif. Elle a aussi pour avantage de ne pas figer la structure du message, sujet sensible. Lapplication SNMP, globale auparavant, se divise prsent en deux sous ensembles (fig 4, pour un agent) :

624

Technologies rseaux avances

snmpEngine : machine (ou moteur) SNMP, charg de linstrumentation du protocole ; Applications : Command Responder dsigne lancienne fonction agent, Notification regroupant TRAP et INFORM (acquitte). Proxy-forwarder est lapplication qui permet de traduire un message dune version SNMP dans une autre version. Les applications sappuient sur ce moteur SNMP, pour changer les units de donnes de protocole (PDU). Ci dessous la reprsentation dune entit agent. Lentit gestionnaire se dduirait aisment (comme indiqu sur la figure 4 ). On notera que la structure modulaire permet ventuellement de faire coexister applications agent (Command Responder) et gestionnaire (Command Initiator), un gestionnaire pouvant se comporter en agent vis vis dun autre gestionnaire. La dmarche du groupe de travail, faire la synthse entre 2 versions concurrentes, ntait pas simple vu la tension qui rgnait dans la communaut SNMP. Il y a eu beaucoup de polmiques avant que les esprits ne se calment. Toutes ces discussions ont retard laboutissement du projet, mais ont oblig les auteurs une rigueur dans la formulation des concepts et dans la rdaction des documents. Cela limitera sans doute les interprtations diffrentes des documents. Mais le retard accumul au fil des annes a lass utilisateurs et constructeurs qui ont entrepris de se tourner vers dautres techniques, principalement axes sur le WEB. On verra plus loin succinctement les solutions offertes sur le march aujourdhui. SNMPv3 est toutefois aujourdhui une ralit. Les concepts dvelopps ont enrichi SNMP et doivent permettre un dploiement sur mesure, avec des outils masquant la complexit de la nouvelle architecture. 2.2 Description de larchitecture de SNMPv3 Figure 4 (Entit SNMP : Machine SNMP + Applications)

Les services entre modules dans une entit SNMP sont dfinis en terme de primitives avec paramtres. Ces mcanismes sont dpendants de limplmentation. On utilise le terme de ASI , Abstract Service Interface pour qualifier le mcanisme de services entre modules. Dans la nouvelle architecture SNMP le sous systme Dispacher est la plaque tournante de lentit SNMP, il change (met ou reoit des primitives) avec : Le rseau pour les messages Les applications transmettant/rceptionnant les units donnes de protocoles (PDU), cest dire les donnes. Le module (MP : Message processing)) de traitement du message (V1, V2c ou V3). Le module de traitement du message (MP) met une primitive destination du module de scurit (USM). Si

625

Technologies rseaux avances

lentit SNMP met un message, USM scurise le message transmettre selon les directives que MP a reu de lapplication (paramtres de temps, remplissage ventuel des champs dauthentification, de cryptage). Dans le cas dun message reu, les contrles de scurit sont effectus selon les directives du traitement message (MP). Dans ce cas, si les paramtres de scurit satisfont aux critres attendus, MP repasse la main lapplication pour traitement des donnes (PDU). Dans le cas dun agent (Command Responder), la primitive dappel au contrle daccs par VACM est initie par lapplication (ASI : isAccessAllowed, paramtres). Il sagit de vrifier que laccs la MIB de lagent est conforme ce qui est permis pour le demandeur ( Principal ) en question. Le mcanisme de contrle daccs est dcrit en dtail plus loin . Il est noter que le sous systme de contrle daccs (VACM), nest prsent que sur un Command Responder. Important : sur un agent (Command Responder) supportant SNMPv3, VACM peut imposer des restrictions daccs des commandes SNMPv1,v2C. En effet une translation directe (mapping) de la communaut en paramtres interprtables par VACM permet cette opration (community-security-Model de SNMP-COMMUNITY-MIB, RFC 2576) qui se rattache aux problmes gnraux de la coexistence des versions SNMP. 2.3 Espace de nommage pour les objets (les plus courants) de larchitecture SNMPv3 Cet espace de nommage rassemble lensemble des objets dcrits dans les RFC 2570 2576. qui composent lentit globale SNMP, et qui se trouvent sous lembranchement 1.3.6.1.6.3, sous snmpModules. On trouve donc les objets manipuls dans les sous systmes MPD (traitement du message), USM (scurit ), VACM (contrle daccs pour un agent), les objets de certaines applications. Figure 5

Contenu des RFC dcrivant larchitecture SNMPv3 Que faut il retenir du contenu de ces nombreuses RFC . Il serait illusoire de penser que les RFC nintressent que les dveloppeurs. Comme dans tous les sujets touchant TCP/IP, il est frquent davoir consulter les RFC pour approfondir un point prcis. De plus la consultation des diffrentes tables aident beaucoup la comprhension des mcanismes. Les RFC qui accompagnent le schma des sous systmes de Larchitecture SNMPv3 (fig 5) clairent principalement 3 points : Les concepts qui sous tendent les fonctionnalits des sous systmes Les primitives (ASI) dans lesquelles le sous systme particulier est impliqu, avec leurs paramtres IN/OUT Les MIB associes qui prcisent le rle des variables utilises par le sous systme. Framework : RFC 2571 (branchement 1.3.6.1.6.3.10) RFC gnraliste qui dcrit larchitecture gnrale modulaire de SNMPv3 , avec la nouvelle approche de lentit SNMP, le mcanisme de scurit deux niveau (message avec USM, accs MIB avec VACM). Toutes les

626

Technologies rseaux avances

primitives entre les sous systmes sont introduites (dtailles dans les MIB des sous systmes). MPD : RFC 2572 (branchement 1.3.6.1.6.3.11) MP ou MPD pour dispaching Cette RFC traite de lensemble traitement du message et aiguillage (Dispacher) vers rseau, applications, et module de scurit. Ce Module traite galement le format du message SNMPv3(description ASN.1) en dtaillant les variables du champ entte du message (voir fig 6). Applications : RFC 2573 (branchements 1.3.6.1.6.3.12,13,14) Ce module dcrit le mcanisme dinteraction des diffrentes applications avec laiguilleur (Dispacher) et pour les applications impliquant un accs la MIB de lagent, la primitive isAccessAllowed (params) destination de VACM. Les variables associes aux applications sont dcrites dans les MIB spcialises. USM : RFC 2574 (branchement 1.3.6.1.6.3.15) Cette RFC rappelle lapproche scurit et protection dans SNMPv3 (reprises de SNMPv2). Le module de scurit doit tre en mesure de fournir les outils suivants : Authentification et intgrit du message Cryptage dune partie des informations Protection contre la rmission de messages retards ou hors squence. Cette RFC dcrit les mcanismes de scurit noncs ci dessus, en nonant les outils actuels disponibles. On insiste particulirement sur la gnration de cls localises , qui nimposent ladministrateur que la gestion dun password habituel. Les mcanismes de cration/suppression dutilisateurs, de changement de cl ( distance) sont traits dans le dtail. Une table importante (usmUserTable) gre les variables associes ces mcanismes. VACM : RFC 2575 (branchement 1.3.6.1.6.3.16) Pour une entit SNMP agent (Command Intiator) , cette fonctionnalit constitue un apport essentiel de la nouvelle architecture. Le mcanisme danalyse des permissions affectes chaque administrateur permet de contrler finement laccs la MIB de lagent. 4 tables rglementent cet accs, les MIBs associes explicitant la fonction des variables. Coexistence and Community based Security Model : RFC 2576 (branchement 1.3.6.1.6.3.18) Pour bnficier des mcanismes de VACM quelle que soit la version de SNMP, il tait important de prvoir une adaptation de SNMPv1 et v2C lenvironnement de SNMPv3. Si lentit agent traite les 3 types de messages SNMP, Cette adaptation est ralise par configuration de lagent qui transforme une communaut en un couple de variables (securityName, securityModel), comprhensible par VACM. 2.4 Points forts du modle : Incontestablement larchitecture modulaire constitue lapport majeur de SNMPv3 et offre dentre une grande souplesse pour intgrer diffrentes options possibles de traitement. Les retombes sont multiples et permettent la fois de prendre en compte lexistant ainsi que de promouvoir une volution indpendante pour les diffrentes composantes de larchitecture. cette approche, absente de SNMPv2 avait condamn lensemble de larchitecture du fait de lchec du volet scurit. On peut relever pour la nouvelle architecture modulaire les caractristiques suivantes : - Structure du module de traitement (MP) multilinguale du message de faon pratiquement native. - Prsence dans chaque sous-systme dune structure daccueil pour option diffrente de traitement. - Possibilit de gestion allge pour des rseaux ne ncessitant pas tous les outils de scurit Relle capacit dadministration distance de faon scurise, y compris pour le maniement des cls. Cette nouvelle approche est conforte par lintroduction de loption TCP en plus de UDP, TCP rpondant mieux aux transferts volumineux rpts en gographique. La facilit de gestion des cls dauthentification et de cryptage (point qui avait condamn SNMPv2) En conservant limpratif de cls diffrentes pour chaque quipement et pour chaque utilisateur, le mcanisme de cls localises (expliqu plus loin) est transparent lutilisateur qui na quun password manipuler. Approfondissement de la fonction proxy-forwarder, trs importante dans la situation actuelle, certains quipements ne supportant quune version de SNMP (quipement ou gestionnaire). Une traduction dune version SNMP dans une autre version simpose dans ce cas. Sophistication des contrles daccs la MIB de lagent (VACM), selon de multiples critres : - Couple (utilisateur, modle de scurit) - sous-ensemble de la MIB (toute larborescence fille dun point de lespace) - options dinclusion ou dexclusion du sous-ensemble de la MIB

627

Technologies rseaux avances

- notion de contextes diffrents dans un mme quipement (avec identifiants diffrents) Capacit dappliquer sur un agent SNMPv3 les fonctionnalits VACM, pour des commandes SNMPv1/v2c Richesse des documents qui dtaillent avec une grande rigueur les fonctionnalits de la nouvelle architecture . 2.5 Principales nouveauts techniques propres V3 1) Notion de Principal : entit au bnfice de laquelle se droule lopration (utilisateur, rseau) 2) SnmpEngineID : identifiant propre lquipement. La structure de cet identifiant peut tre trs varie[1], mais le plus souvent il est construit partir du code constructeur dune part et de ladresse IP ou encore MAC (cisco prfre ladresse MAC). 3) La communication entre les diffrents sous systmes seffectue sous forme de primitives (ASI cits plus haut) dont le mcanisme est introduit dans la RFC 2571 gnraliste sur SNMPv3, et prcis dans les diffrentes MIBs spcialises. Le livre de Stallings [10] explique bien ces mcanismes 4) Utilisation dune nouvelle PDU (REPORT) rserve exclusivement la communication entre machines SNMP. Cette PDU introduite par SNMPv2 navait pas pu tre utilise. 5) Les nouvelles fonctionnalits des tables, introduite par le SMIv2 sont pleinement utilises (cration/suppression dynamique de ranges dans les tables, indices pouvant ne pas appartenir la table, indices rendus non-accessibles). 6) Le mcanisme de gnration des cls dauthentification et de cryptage tait dj introduite dans les pre-versions V3 concurrentes (SNMPv2U, SNMPv2*). La moulinette (Hash function) qui gnre une cl localise (par quipement) partir de lidentifiant snmpEngineID, et du password (par utilisateur) est dcrite dans Stallings [10] et dans la RFC2574. 7) La notion de temps authoritative , cest dire qui prvaut. Cest le Command Responder (agent) qui dtient le temps. Ce temps est contenu dans deux objets (nombre de redmarrages de lquipement, temps coul depuis le dernier redmarrage). On na pas retenu le maintien (trop dlicat) dune horloge absolue. Lors de laccs de lagent, le temps figurant dans le message ne doit pas diffrer de +/-150s de celui de l agent (nombre de Boots tant en accord). Sinon le message est rejet comme non authentique.. 8) Cration dutilisateurs : le processus de cration des utilisateurs sur lagent rappelle le mcanisme dans un systme dexploitation. On procdera au clonage dun utilisateur existant (clonage en gnral limit une opration). Lutilisateur doit ensuite changer son password (ce qui changera sa ou ses cls de scurit sur cet quipement). 9) Le changement de cl peut se faire distance, sans cryptage en toute scurit (cette condition est ncessaire du fait que lutilisation cryptage nest pas une obligation dans SNMPv3). Il est toutefois conseill de crypter si possible cet change. Le mcanisme astucieux est dcrit dans RFC2574 page 34-35. 2.6 Points faibles du modle SNMPv3 La modularit de larchitecture rend lensemble plus difficile comprendre Chaque sous systme gre ses tables et on trouvera de ce fait le mme objet sous des noms diffrents (par exemple snmpEngineID, contextEngineID, msgAuthoritativeEngineID). La latitude future laisse aux dveloppeurs dajouter des options de traitement (mention other dans les sous (systmes) ouvre la porte une drive qui peut menacer terme la compatibilit des produits. Dans un autre domaine (X25) la multiplicit des options avait men des implmentations nationales incompatibles de fait entre elles. Malgr un travail en profondeur considrable, SNMPv3 demeure un modle scalaire, et reste lcart des techniques objet qui rpondent mieux aux contextes actuels de dveloppement. Lidentifiant de la machine SNMP (snmpEngineID) peut tre construit de multiples faon. Les risques de duplicate sont rels et beaucoup pensent quil fallait exclure lutilisation de ladresse IP dans la construction de cet identifiant. Peut tre le plus important : les grands acteurs de ladministration rseau ne sont pas encore convaincus dinvestir dans SNMPv3. 2.6 Structure du message Laction des diffrents sous systmes se traduit dans la composition du message (figures 4 et 6). La structure du message se divise en 4 champs : 1) version du message, permettant au Dispacher dorienter le message vers la bonne version de traitement (la capacit multilinguale conseille pour les entits SNMPv3 actuellement)

628

Technologies rseaux avances

2) msgGlobalData, produisant les informations de service qui alimentent le sous systme de traitement du message (MP), entre autres : msgMaxsize : taille maximum du message support par lexpditeur du message. msgFlags : masque indiquant le degr de scurisation du message, ainsi que la possibilit ou non de provoquer une PDU REPORT en retour (PDU de service entre machines SNMP) msgSecurityModel : actuellement ne peut tre que 3 (USM) dans un tel message. 3) MsgsecurityParameters On retrouve une partie des objets prsents dans la table USM. (identifiant Engine, paramtres de temps de la cible, Principal, et selon le degr de scurit, le rsultat de lapplication des cls sur le message (Salt values). 4) ScopedPDU La PDU est accompagne (dans le cas gnral) de son nom de contexte et de lidentifiant correspondant. Pour illustrer le cas de contextes diffrents, un switch ATM par exemple, pourrait affecter chaque interface un contexte diffrent, les adresses IP et MAC tant diffrentes. A ne pas confondre avec snmpEngineID correspondant ladresse sous laquelle cet quipement rpond. 2.7 Droulement des oprations Le message donn en exemple est le rsultat de lopration, la rponse du Responder lInitiator. Pour parvenir communiquer avec le Responder, cela suppose que lexpditeur (lInitiator) connaisse du destinataire (Responder), outre les cls requises, les renseignements suivants : Lidentifiant snmpEngineID cible Les paramtres de temps de la cible (Responder) snmpEngineBoots et snmpEngineTime Dans le cas tudi, si le processus de dcouverte du gestionnaitre (Initiator) na pas enregist la machine authoritative, il doit y avoir une premire requte avec les champs de scurit vides. Le responder rpond par une PDU REPORT (service entre machines SNMP), qui contient les paramtres dsirs. Un deuxime get-request avec un message complet permettra le succs de lopration. Exemple de commandes SNMP mode ligne avec NET-SNMP (ancien UCD-SNMP) sur LINUX Exemple de commande SNMPv1
snmpget v 1 localhost public .1.3.6.1.2.1.1.4.0 1.3.6.1.2.1.1.4.0 (sysContact) = M.Dupont (communaut = public )

une commande SNMPv2C aurait la forme snmpget v 2C .

Exemple de commande SNMPv3 (exemple tudi plus loin)


Snmpget v 3 l autNoPriv u xavier a MD5 A passsnmpv3 localhost .1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0) Value: Timeticks: (249447) 0:41:34.47

Dans le mode ligne de NET-SNMP sur LINUX, tous les paramtres sont donns au vol Le niveau de priorit : Lutilisateur (Principal) Le protocole dauthentification Le password de xavier La cible (ici localhost) LOID de la variable cible autNoPriv : (authentification mais pas de cryptage) xavier MD5 passsnmpv3 (lequel moulin avec EngineID => cl dauthentification) 1.3.6.1.2.1.3.0 : sysUpTime du groupe systme, (.0) pour instance unique

629

Technologies rseaux avances

Figure 5
. Frame 36 (167 on wire, 167 captured) Simple Network Management Protocol Version: 3 Message Global Header Message Global Header Length: 13 Message ID: 9 Message Max Size: 1472 Flags: 0x01 .... .0.. = Reportable: Not set .... ..0. = Encrypted: Not set .... ...1 = Authenticated: Set Message Security Model: USM Message Security Parameters Message Security Parameters Length: 46 Authoritative Engine ID: 800007E501869E619D Engine Boots: 5 Engine Time: 2494 User Name: xavier Authentication Parameter: DA4D094554A2946557EB7F74 Privacy Parameter: Context Engine ID: 800007E501869E619D Context Name: PDU type: RESPONSE Request Id: 0x8 Error Status: NO ERROR Error Index: 0 Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0) Value: Timeticks: (249447) 0:41:34.47

630

Technologies rseaux avances

2.8 Avance fondamentale : la scurisation des changes en deux phases La scurisation dans SNMPv3 est ralise deux niveaux : Niveau du message : pris en charge par le sous systme de scurit , actuellement USM pour SNMPv3 Community Security Model pour SNMPv1 ou v2C. Authentification de la source, contrle de lintgrit du message Eventuellement cryptage des informations protger (on notera quil est possible de travailler sans authentification ni cryptage, mais pas sans contrle de la fentre en temps). Contrle du timing pour viter les manipulations de r-mission ou modification de squence (maximum de +/- 150s dcart pour laccs la machine authoritative , si le nombre de redmarrage concide). Laccs la machine non authoritative est moins svre, le temps du message entrant ne devant pas retarder de plus de 150s. Niveau du contrle daccs aux objets de la MIB, lorsque le niveau prcdent (authentification, intgrit du message, contrle de la fentre en temps, ventuellement cryptage) est valid VACM est actuellement le seul mcanisme de contrle daccs retenu dans SNMPv3. Rappelons que le contrle daccs sur la MIB dun quipement, supportant SNMPv3, sera applicable des commandes SNMPv1 ou v2C. Cest un des points remarquables de la nouvelle architecture. Ce deuxime niveau de scurit est rglement par les objets des diffrentes tables du sous-systme VACM dont les fonctionnalits sont donnes ci dessous. Le diagramme dtat figure 7 explicite le rle des objets impliqus. SecurityToGroupTable La premire vrification est ralise au niveau du couple (securityName, securityModel) , le Principal qui essaye daccder doit tre associ un modle de scurit, et appartenir un groupe figurant dans la table securityToGroupTable . Il est important de voir quon peut trouver des groupes dont le modle de scurit est SNMPv1, ou v2C. Un couple (securityName, securityModel) ne peut appartenir qu un groupe, mais un Principal (securityName) peut appartenir plusieurs groupes avec des modles de scurit diffrents. Le modle de scurit v1 ou v2C, avec securityName associ est driv de la communaut (voir MIB SNMP-COMMUNITY-MIB dans la RFC 2576 traitant de la coexistence entre versions de SNMP). VacmContextTable On peut tre amen distinguer dans un quipement des zones traiter sparment les unes des autres (on a voqu des interfaces de commutateurs ATM par exemple, considrs comme des contextes diffrents). Cette table contiendra les noms des contextes. VacmAccessTable Cette table dtermine la nature de laccs demand (Read/Write/Notify). Quatre index (groupe, modle de scurit, niveau de scurit, et nom de contexte) dterminent la nature de lopration. VacmViewTreeFamilyTable Cette table va conditionner la granularit plus ou moins prcise de laccs . lOID SubTree (toutes les instances filles dun point de lespace de nommage), pourra tre inclus ou exclu de laccs (included/excluded) avec un raffinement procur par un masque qui prcisera sur lOID de subTree, les instances prcises que lon veut inclure/exclure du champ daccs. Les instances qui peuplent ces tables conditionnent le rsultat de la primitive isAccessAllowed, rsultat qui autorise ou non finalement lopration sur linstance de lobjet cible.

631

Technologies rseaux avances

Diagramme Dtat de la primitive daccs au sous-systme de Contrle dAccs Status= isAccessAllowed (securityModel, securityName, securityLevel, viewType, contextName, variableName)

Figure 7

3. Coexistence entre les versions SNMPv1, V2c et V 3:


Limportance du parc install SNMPv1 et v2c imposait que le nouveau protocole prenne en compte lexistant, dune faon aussi transparente que possible pour lutilisateur. Sil est assez ais dquiper les gestionnaires des moyens de communiquer avec les diffrentes versions de SNMP, le problme des agents ne supportant quune version de SNMP ncessitait dtre trait avec soin. Cette situation avait dj t rencontre avec la coexistence entre version V1 et V2c. Des modules MIB crits selon le SMIv1 peuvent continuer tre accds par des versions de protocole utilisant des PDU SNMPv2. Toutefois , si on veut tre en conformit avec le SMIv2, un certain nombre de changements (environ 20) doivent tre apports dans la modification de la MIB crite en SMIv1[6 ].

632

Technologies rseaux avances

Deux autres types de situations de coexistence sont considrer : 1) Les entits en prsence sont les suivantes : Gestionnaires ou agents ne parlant que V1 ou V1 et V2C 2) Gestionnaires et agents supportant V3 et en pratique capables de communiquer en V1 et V2C Les mcanismes pour communiquer avec des entits de versions SNMP diffrentes sont de deux sortes : Capacit multilinguale Application proxy-forwarder cot de lapplication principale (Initiator, responder ). La fonction multilinguale est par exemple ce quon doit trouver dans le sous systme MP (Message Processing) dans les entits SNMP implmentant la nouvelle architecture, cot gestionnaire et cot agent (MP pour V1, V2C, V3). Le seul rel problme est linterrogation par une entit gestionnaire SNMPv1 dune variable 64 bit provenant dun agent crit selon les rgles du SMIv2. La traduction de la fonction proxy en SNMPv1doit ignorer ce type de variable. Une autre situation est celle qui permet dutiliser les fonctionnalits de VACM, (limitation de laccs la MIB de lagent) dans le cas dune requte provenant dun gestionnaire V1 ou V2c. Une MIB (snmpCommunityMIB) dcrit les objets qui sont utiliss, permettant la translation communaut (securityName, securityModel). On a ainsi dfini des valeurs de securityModel pour V1(=1) et V2C(=2) ainsi que messageprocessingModel pour V1 (=0) et V2C(=1). Un mcanisme Community-based Security Model va tre invoqu en plus des modles de traitement V1/V2C prsents dans le sous systme MP de la nouvelle architecture. Il faut souligner que ces mcanismes, fonctionnant dans les deux sens, sont invoqus par la fonction proxy-forwarder. Bien entendu un passage de V1/V2C V3 ne peut donner que noAuth/noPriv comme niveau de scurit, une translation dans lautre sens perdant le niveau de scurit comportant authentification ou cryptage.

4. Position des constructeurs vis vis de SNMPv3


Les constructeurs ont t partags entre les deux versions concurrentes au milieu des annes 90. Aujourdhui force est de constater que leur attitude varie entre lattentisme, quelques implmentations dvaluation (cisco), ou encore la superbe ignorance du nouveau protocole. On peut dire que depuis deux annes, les spcifications sont suffisamment prcises pour implmenter SNMPv3 dans les gestionnaires et dans les agents. Pour les gestionnaires, de petits constructeurs ont fait leffort (SNMPC de Castlerock, MG-SOFT et dautres). Ajoutons aussi le remarquable travail de NET-SNMP (ancien UCD produit libre offrant agent et gestionnaire SNMPv1, v2C, v3 en mode ligne sur la plupart des plates-formes UNIX et Windows) . Position de HP : HP porte une lourde responsabilit dans lattentisme de la communaut SNMP. La plate-forme HPOV est la rfrence dans le monde de ladministration rseau. Le retard de HP intgrer en natif le nouveau protocole a t interprt que comme une marque de dfiance vis vis de SNMPv3. La solution (un peu confidentielle) de HPOV pour travailler en SNMPv3 est dacqurir le logiciel commercial de SNMP RESEARCH ce qui nest pas ce quon pourrait attendre dun grand constructeur comme HP. La consquence est que lensemble des matriels HP ignore SNMPv3 et privilgie lvidence les techniques WEB. Position de CISCO Cisco a introduit SNMPv3 partiellement sur certaines lignes de matriels (36XX , et 7000). Un aperu est donn dans lexemple qui suit, les fonctionnalits tant assez correctement vrifies. Les autres matriels CISCO (switch 35XX ou 29XX) acceptent les instructions de configuration V3 mais redmarrent quand on applique une commande V3. En labsence dinformations de relles implmentations SNMPv3 dans des quipements rseaux, on se limitera donner en annexe un apercu de lexploration dun serveur PPP 3640 de Cisco, accd par un gestionnaire SNMPv3 UCD-SNMP sur LINUX. Les rsultats avec un gestionnaire MG-SOFT (graphique) donnent les mmes rsultats

633

Technologies rseaux avances

4.1 Exemple de fonctionnement dquipements SNMPv3 Ce dveloppement a t pris en charge par un stagiaire dcole dingnieur [7] au LAPP en 2000 sur un serveur PPP CISCO, (IOS 12.X) supportant SNMPv3. Cest un des rares quipements que nous avons pu tester assez loin avec SNMPv3. La version complte de lexploration SNMPv3 avec lensemble des programmes PERL est donne en rfrence [18]. Le traitement des TRAP RNIS (NUMERIS) permettrait de comptabiliser les temps de connexion si cela tait souhait. Lanalyse des TRAP (v2C) nous a permis pendant quelques mois de vrifier priodiquement lorigine des appelants. 4.2 Evolution de SNMP La retenue du march sengager franchement dans le dploiement de SNMPv3 ont incit les parties prenantes rflchir sur les orientations futures de ladministration des rseaux ; Le travail de rflexion sur lvolution de SNMP et de son environnement est men dans deux groupes de travail, EOS (Evolution Of SNMP) et SMIng (ng pour New Generation): SNMP est reconnu comme un mcanisme lgant pour changer des messages bien formaliss entre entits. Cependant combien dachats de plate-formes onreuses, censes apporter des solutions, se rsument finalement une implmentation dun mcanisme simple qui est denvoyer des ping 24H/24, 7 jours/7 . On esprait quelque chose de simple installer, utiliser et comprendre (une solution finale en somme) et on saperoit que linvestissement en temps est lourd pour matrialiser une administration digne de ce nom. Le protocole SNMP est simple, mais la difficult rside dans la comprhension du contenu des MIBs, spcialement des MIBs constructeurs. La voie qui pourrait apporter un plus est peut tre de complter cette structure de donnes difficile apprhender par de lintelligence prpare spcialement son environnement. On pense des multiples et trs lgers plug-in , add-on , peu onreux qui pourrait enrichir spcifiquement les plate-formes gnriques. Cette approche, qui rejoint les approches alternatives SNMP, est envisageable pour deux raisons : Lintelligence embarque dans les quipements est sans commune mesure avec la situation des dbuts de SNMP Les rseaux ont dpass lpoque ou on vivait dans lattente de la panne rparer. Aujourdhui les rseaux sont robustes et prts accepter une distribution cooprative de lintelligence. 4.3 SMIng (ng pour New Generation), groupe EOS (Evolution Of SNMP) Le but au dpart du groupe de rflexion SMIng tait de sattaquer aux imperfections du SMIv2 et devait aboutir une proposition pour un SMI renouvel (SMIng). Les valuations ont t conduites dans lenvironnement dun projet parrallle libsmi , en y adjoignant un pr-compilateur (parser) ainsi quun genrateur de code. Les rsultats dune premire tape ont t rassembls dans une prsentation [14]. Le groupe de travail SMIng travaillait alors sous lgide de lIRTF/NMRG (Network Management Research Group, IRTF Internet Research Task Force affili IETF). Un certain nombre de documents ont t produits : Une grammaire formelle (ABNF, Augmented Backus-Naur Form, RFC 2234) Trois modules MIB (core MIB modules) LIETF sest alors impliqu dans le processus en crant le groupe SMIng , dont les futures spcifications doivent tre regroupes dans 4 parties distinctes : Spcifications pour un langage de base dans SMIng (core language) Spcifications pour les modules de base dans SMIng (core modules) Extensions du langage pour application SNMP Extensions de langage pour adapter aux spcifications COPS-PR Plusieurs Drafts ont t produits SNMP Extended Protocol MIB SNMP Row Operations Extensions SNMP Object Identifier Compression Efficient Transfer of Bulk SNMP data SNMP Bulk Data Transfer Extensions Les rflexions de ces groupes de travail sattaquent aux aspects critiqus de longue date dans le SMI, imparfaitement corrigs dans les versions successives du SMIv1 et SMIv2. Outre les types oublis au dpart (64 bit), qui ont caus tant de tracas, on pense avoir besoin dans le futur peut

634

Technologies rseaux avances

tre du type FLOAT, et peut tre dautres types de donnes. Le manque doutils pour sassurer de la rigueur dcriture des MIBs demandent des manipulations rptes pour corriger la formulation de nombreuses MIBs, y compris celles en provenance de lIETF. Une couche supplmentaire libsmi, munie dAPI, chapeautant les pr-compilateurs ( parsers SMIv1/v2, SMIng, GDBM) est ltude pour rendre plus rigoureuse lcriture des MIBs ; Le nommage des variables par OID rptant le chemin complet est trop lourd. Lencodage BER aggrave ce dfaut. Un nouvel encodage, PER Packed Encoding Rules [20], utilise un mcanisme diffrent du TLV de BER . PER privilgie un encodage bas sur le type de donne pour gnrer une reprsentation plus compacte. Le Type de TLV nest gnr que si cela est ncessaire pour viter une ambigut (cas dutilisation de CHOICE : version ASN.1 de UNION). PER gnre en outre la longueur en octet de la valeur uniquement lorsque la taille de lobjet varie. PER essaye nanmoins dencoder de faon plus conomique. Les exemples cits dans la rfrence mettent en vidence un gain considrable (rapport jusqu 5 :1). Enfin une extension des mcanismes de transfert de masse des donnes est galement en chantier, le GETBULK ne rpondant pas suffisamment aux exigences actuelles. Le calendrier de travail devait se drouler au cours de lanne 2001, avec dcision en octobre de poursuivre ou darrter le groupe de travail.

5. Solutions alternatives ou associes SNMP : coexistence HTTP et SNMP


Les remarques faites pour lvolution de SNMP (intelligence accrue dans les quipements, omniprsence du WEB) sont applicables aux approches alternatives ou complmentaires. Ces approches seront simplement cites , avec rfrences pour tude plus complte. La prsentation diapositive privilgie les schmas et fonctionnalits de ces architectures. 5.0 CMIP/CMIS de OSI Ladministration OSI est antrieure SNMP et les concepts de ladministration ont t pos par OSI. CMIP/CMIS a suivi le destin des produits OSI, qui se cantonnent dans des niches confidentielles. Les dploiements de CMIP/CMIS comptent quelques secteurs trs particuliers (surveillance radar europenne de laviation civile, certains secteurs des telecoms). Pour des institutions qui avaient un besoin impratif de scurit, pour lesquelles le cot de linstallation ntait pas dissuasif, CMIP/CMIS constituait une rponse. Les applications OSI satisfont au modle OSI, et sappuient indiffremment sur le mode non connect de OSI ou sur le mode connect. Cette dmarche est possible si on accepte de constituer un ensemble isol, reli par lignes spcialises par exemple. Aujourdhui, larrive de SNMPv3, le poids de TCP/IP doivent amener les utilisateurs de CMIP/CMIS sinterroger sur la prennit de leur choix. 5.1 MRTG (Multi Router Traffic Grapher) On ne peut parler de SNMP et du WEB sans se rfrer une des premires tentatives de marier SNMP et le WEB. Ecrit en langage PERL, MRTG tourne sur de nombreuses plates-formes UNIX (LINUX essentiellement). Le mcanisme est simple : lecture dune variable intervalles priodiques (5mn par dfaut), gnration de pages WEB contenant des images GIF, visualisation par un navigateur WEB de lhistorique des valeurs prises par la variable mesure. Cette approche est classer dans la rubrique des techniques de Monitoring , SNMP effectuant des GETREQUEST , cest dire des lectures de compteurs essentiellement. La surveillance par graphiques retraant une historique sapplique tout quipement (routeurs, stations, switches) Cette technique est souvent associe iptraffic, permettant de suivre lvolution dune distribution de protocoles sur une interface de routeur par exemple.

635

Technologies rseaux avances

5.2 EWBM (Embedded Web-Based Management) Dans cette approche, un serveur WEB est implant dans lquipement qui possde une adresse HTTP. On parle alors dun agent WEB lequel communique par HTTP avec une application dadministration. Un agent WEB peut tre sophistiqu compar lagent SNMP. Un autre avantage EWBM est quil peut tirer avantage des outils portables pour crire lagent WEB (par exemple WEB agent et WEB serveur peuvent tre crits en JAVA. On peut trouver des exemples dimplmentations commerciales dagents WEB, mais elles sont bases sur des protocoles propritaires. La plupart des constructeurs dquipements rseaux ont une offre dagent WEB dans leur Hubs et Switches. Ces agents WEB coexistent et communiquent le plus souvent avec lagent SNMP. La communication avec lapplication de gestion couple au navigateur (Advance Stack Assistant chez Hewlett Packard) se fait par HTTP. Pour les switches, cette mthode est moins coteuse que la sonde RMON attache chaque port. 5.3 DMI (Desktop Management Interface) DMI est un standard de lindustrie produit par le consortium DMTF (Desktop Management Task Force) cr en 1992). Le but de DMTF tait de dvelopper et maintenir des outils de gestion standard pour les PC. DMI se situe entre les composants des architectures machine et les logiciels qui les grent. Des entits component Agents , qui peuvent tre du logiciel (scruteur de virus), ou matriel (carte rseau) dialoguent avec une application rsidente Desktop management travers DMI. DMI consulte une base de donnes au format MIF (Management Information Format comparable la MIB de SNMP, utilisant aussi ASN.1) et communique avec les deux entits par le jeu dAPI. Le but est darriver grer toutes les plate-formes sur un rseau de faon centralise, indpendamment du constructeur et du systme dexploitation (DMI 2.0). DMI est assez diffrent de SNMP ; toutefois une tentative pour intgrer DMI dans SNMP a t tente mais sans succs. Entre 1996-98, la mission de DMTF a t largie pour intgrer les standard de gestion existants (SNMP, CMIP, DMI et HTTP) et promouvoir le projet WBEM (Web Based Entreprise Management). Limplication de Microsoft dans ce projet pourrait lui assurer une place significative dans la gestion des rseaux de PC. 5.4 Approche WBEM (Web-Based Entreprise Management) Ne dune initiative de constructeurs mi 97 (Cisco, Intel, Compaq, BMC, Microsoft ), cette approche dfinit une charte commune ayant pour objectif de trouver des solutions dadministration interoprables, mais en intgrant les techniques existantes. Cette solution intgre CIM (Common Information Model) de Microsoft Cela implique les points suivants : Description commune des donnes, indpendante de la plate-forme Protocole standard de publication des donnes et daccessibilit de ces donnes. WBEM na pas lobjectif de remplacer les protocoles tablis (SNMP, et aussi CMIP) mais est cens intgrer ces techniques. Le navigateur WEB constitue linterface utilisateur. Larchitecture dtaille de WBEM peut tre trouve dans les documents cits en rfrence [11] et [15] Avantages de cette approche : Rduit la complexit des solutions dadministration, puisquelle offre, par un navigateur WEB, une visualisation complte des donnes dadministration. 5.5 Approche JMAPI (Java Management API), JMX (Java Management Extensions) , EJB (Entreprise Java Beans) Il sagit la aussi dune initiative constructeurs (SUN tant lacteur principal, avec CISCO, Novell, Bay Netwokset dautres). Cette solution base de classes et dinterface JAVA est rsolument objet . On retrouve la reprsentation et la modlisation uniforme des donnes. On trouvera une description de ces mcanismes en rfrence [17]. Avantages : JAVA est indpendant du systme et vite la gestion dune plate-forme onreuse. Cette approche est sans doute promise des dveloppements, la concentration de lintelligence dans les quipements tant une donne riche de promesses. Inconvnients : lenteur excluant la gestion de grands rseaux, manque de rgles tablies pour implanter ces technologies.

Conclusion :

636

Technologies rseaux avances

A la question concurrents ou complmentaires , Nous savons maintenant que pour les petits rseaux, la gestion directe de lquipement par le WEB est suffisamment attrayante pour supplanter la plate-forme onreuse comme outil principal. Pour les grands rseaux, SNMP reste et restera loutil incontournable, mme si linterface utilisateur peut utiliser le WEB comme interface utilisateur (HP Openview peut tre lanc partir dun navigateur WEB). SNMPv3 doit encore simposer et surmonter la rticence de la communaut SNMP. Les utilisateurs resteront sur la rserve tant que les grands acteurs du monde des rseaux et telecoms nauront pas franchement donn leur appuis au nouveau protocole. Les fonctionnalits sont riches et permettent dadministrer de faon scuris un rseau en gographique, ce qui tait impossible jusqu prsent. Donc SNMPv3 simposera car le besoin de scurit est exig dans le monde ouvert de lInternet. Larrive progressive des quipements (agents) compatibles SNMPv3 permettra de franchir une premire tape : se familiariser avec les gestionnaires existants SNMPv1/v2C pour organiser des hirarchies dutilisateurs avec des droits daccs diffrents sur la MIB de lquipement. On peut esprer que les logiciels de gestion intgreront en natif le nouveau protocole, dcision indispensable pour convaincre la communaut SNMP. Comme souvent dans le pass, les petits dveloppeurs de plateformes de gestion, aujourdhui prts pour SNMPv3 entraneront les grands noms (Openview Network Node Manager de HP en particulier). Pour la gestion de parcs de machines, SNMP avec plate-forme de gestion est moins attrayant pour les administrateurs systme habitus leur techniques propres. Cependant les techniques prnes par DMTF, aprs lchec relatif de SMS (System Management Server de Microsoft) auront leur place conforte par Microsoft, couple un navigateur WEB. Il reste percevoir les grandes tendances qui se dessinent assez nettement aujourdhui. Le modle PULL initiative prfrentielle du gestionnaire, mis en place par SNMP voluera de plus en plus vers le modle PUSH , initiative croissante de l quipement grce lintelligence implante. Les solutions en gestation aujourdhui sintgreront de plus en plus dans le WEB, qui devient lespace de travail prfrentiel. Lextrme diversit des solutions alternatives SNMP, riches de promesses mais encore non stabilises, plaident en final pour SNMP, protocole bien accept et enfin finalis. Rfrences [1] RFC 2571 An Architecture for describing SNMP management Framework [2 ] RFC 2572 Message Processing and Dispaching for SNMP [3 ] RFC 2573 SNMP Applications [4 ] RFC 2574 User-based Security Model (USM) for version 3 of SNMP [5 ] RFC 2575 View-based Access control Model (VACM) for SNMP [6 ] RFC 2576 Coexistence between version 1, 2, and 3 of managtFramework [ 7] Xavier Fournet - Configuration dun serveur PPP cisco 3640 dans lenvironnement SNMPv3 - (stage Ecole dIngnieur INSA au LAPP- t 2000) [8 ] 10th IFIP/IEEE International Workshop on Distributed systems, Zurich, Oct 11-13, 1999 [9 ] T.Marshall Rose (livre) The Open Book [10] W.Stallings (livre) SNMP, SNMPv2, SNMPv3 (3rd Edition) [11] Mani Subramanian (livre) Network Management [12 ] David Perkins Understanding SNMP [13 ] The Simple Times publications sur le WEB [14 ] F.Strauss SMIng, DSOM99 ETH Zrich, 12.10.1999 [ 15] Winston Bumpus DMTF Comdex Network Management presentation, April 3 2001 [16 ] J.P. Martin-Flattin Gestion des rseaux IP base sur le WEB (GRES99 Montral juin 99 ) [17 ] Ylian Saint-Hilaire Mmoire de Maitrise - Montral [18] Site WEB du LAPP wwwlapp.in2p3.fr [19] Jeff Case Evolution of SNMP - 50th IETF Minneapolis, MN march 18, 2001 [20] Introduction to ASN.1 and the Packed Encoding Rules (http://www.w3.org/HTTP-NG/asn.1.html)

637

Technologies rseaux avances

ANNEXE A Le Langage ASN.1 et lencodage BER (Basic Encoding Rules) Par rapport OSI, les types primitifs sont rduits (INTEGER, OCTET STRING, OID, NULL). On trouve ensuite les type construits, SEQUENCE (concatnation de primitifs ), les type drivs des primitifs ((restriction des valeurs permises au type primitif). Quelques additifs sont en annexe. On donne ci dessous un exemple de la grammaire (ASN.1) utilise pour crer les variables de la MIB standard. Le rsultat de cette invocation (instruction OBJECT TYPE)cre un objet sysContact du groupe system: sysContact est fille de lobjet system, lui mme fille de lobjet mib-2 , etc Les attributs de cet objet sont les suivants : SYNTAX : une variable a un type primitif, construit ou driv dun type primitif STATUS : son statut (mandatory = obligatoire) tout agent SNMP doit incorporer cet objet ACCESS : les oprations possibles sur cet objet : RW (accs possible en lecture et en criture) DESCRIPTION : description textuelle de la fonction de la variable cre : := son assignation dans lespace de nommage : system 4 signifie que sysContact est la variable No 4 du groupe system (1.3.6.1.2.1.1), et doit scrire alors 1.3.6.1.2.1.1.4 Le mme mcanisme est mis en uvre pour la cration de la variable No 5 (sysName) du groupe system

figure 3 On rappellera que la MIB standard (MIB-1 puis MIB-2) ne comportait au dpart surtout des variables gnralistes que tout quipement devait pouvoir intgrer. Par la suite des groupes de travail spcialiss ont dvelopp des extensions au standard (MIB HUB, BRIDGE) qui ont progressivement enrichi lespace non constructeurs, lesquels avaient de moins en moins de raisons de poursuivre le dveloppement de leurs MIBs prives Accs aux variables : Le dialogue entre entits SNMP sur le rseau doit tre indpendant des structures informatiques internes dans les quipements. Cest le rle de lencodage BER (Basic Encoding Rules), syntaxe concrte qui dtaille la structure des donnes sur le rseau). Cest un mcanisme plus lourd que XDR (External Data Representation) , qui remplit la mme fonction dans TCP/IP. On verra que cest un des points que lon tente de simplifier dans lvolution de SNMP. . Toute variable circulant sur le rseau sannonce de faon prcise (TLV pour Type Longueur Valeur). T dans TLV distingue 4 types de variables avec une tiquette dans T pour la variable prcise. Universal simples ou construit : (INTEGER, OCTET STRING , SEQUENCE) Application : (types connus dans S NMP seulement : IpAddress, Counter, Gauge ) Context spcifique : (utilis pour annoncer le dbut dune PDU) Private : prvu pour usage constructeur (en fait pas utilis)

638

Technologies rseaux avances

Exemple : la communaut public , dans le message SNMP on aura TLV : 04 06 7075626C6963 04 indique Universal OCTET STRING 06 annonce 6 octets 7075626C6963 annonce public Commentaires sur les bizarreries de manipulation des tables :

639

Technologies rseaux avances

ANNEXE B Aperu dadministration SNMPv3 sur un quipement cisco (serveur PPP) Les tests complets figurent sur le serveur WEB du LAPP. Ce serveur PPP 3640 est le seul quipement sur lequel les fonctionnalits SNMPv3 ont pu tre tests. Le rsum ci dessous donne un aperu de la dmarche familire de CISCO pour intgrer le protocole SNMP. En fait le terme de SNMPv3 napparat pas vraiment, et la configuration SNMPv3 peut presque tre ralise en ignorant quil sagit du nouveau protocole. 1. Configuration de la 3640 pour SNMPv3 1.1 Cration dun nouveau groupe snmp-server group lapp v3 auth read v1default write v1default cre un nouveau groupe lapp avec un accs SNMPv3 authentifi. La vue accessible en lecture et en criture est v1default 1.2 Cration dun nouvel utilisateur snmp-server user Xavier lapp v3 auth md5 abcdefgh cre un nouvel utilisateur Xavier dans le groupe lapp avec une authentification par MD5. Le password est abcdefgh. 1.3 Visualisation des paramtres SNMP On peut visualiser les paramtres relatif SNMPv3 : lapp-cisco#show snmp engineID Local SNMP engineID: 00000009020000D0BAB69850 Remote Engine ID IP-addr Port lapp-cisco#show snmp group .... groupname: lapp readview :v1default notifyview: <no notifyview specified> row status: active .... lapp-cisco#show snmp user User name: Xavier Engine ID: 00000009020000D0BAB69850 storage-type: nonvolatile active On remarque que lengineID nest pas un engineID version v3. On retrouve donc lancienne structure compose de 12 octets, les 4 premiers reprenant le code constructeur (9 pour CISCO) le reste tant spcifique chaque constructeur. Ici CISCO choisi de reprendre ladresse Ethernet de la 3640. 1.4 Test de la configuration avec ucd-snmp On peut donc tester cette configuration depuis une machine avec ucd-snmp : [root@lappc-in14 mib3640]# snmpgetnext -v3 -l authNoPriv -u Xavier -a MD5 -A abcdefgh lapp-num system system.sysDescr.0 = Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3640-IS-M), Experimental Version 12.0(19990819:200511) [rfh-120CSCdm27848t 129] Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Fri 20Aug-99 14:31 by rfh En cas de mauvais password on obtient bien une erreur : [root@lappc-in14 mib3640]# snmpgetnext -v3 -l authNoPriv -u Xavier -a MD5 -A tototiti lapp-num system snmpgetnext: Authentication failure

security model:v3 auth writeview: v1default

640

Technologies rseaux avances

Glossaire : ASN.1 BER CMIP CMIS CMOT EOS PDU Abstract Syntax Notation Nb 1 : langage de description utilis pour crire les MIB et le cadre dadministration (SMIv1 et SMIv2) Mthode dencodage habituelle de lASN.1 Common Management Information Protocol (administration rseau de OSI) Common Management Information Service CMIP Over TCP (tentative avorte dutiliser CMIP/CMIS au dessus de TCP/IP Evolution Of SNMP (groupe de travail pour la dfinition du futur de SNMP) Protocol Data Unit (Message SNMP v1 : version, communaut, PDU (cad les donnes)) SNMPv1 : Get-request, get-next-request, get-response, set-request, trap SNMPv2 : Get-request, get-next-request, getbulk, response, set-request, trap, inform, report PER MP Principal SMI SMIv1 SMIv2 SMIng SNMP SNMPv2C SNMPv2p SNMPv2U SNMPv2* USM VACM Packed Encoding Rules Message Processing: V1, V2C, V3 conseills) (mthode dencodage de ASN.1 plus compacte que BER) sous systme de traitement du message dans SNMPv3

Entit au bnfice de laquelle se droule une opration SNMPv3 Structure of Management Information : cadre dadministration de SNMP Cadre dadministration pour SNMPv1 (RFC1155 et 1212) Cadre dadministration pour SNMPv2 repris presque inchang pour SNMPv3 Futur cadre dadministration pour SNMP ltude actuellement Simple Network Management protocol (lanc fin des annes 90) version de SNMP avec message de SNMPv1 mais utilisant SMIv2 (1995) SNMPv2 party based (1993) version de SNMP qui a chou pour le volet scurit version de SNMP scurise oppose SNMPv2p version de SNMP scurise concurrente de SNMPv2U User based security Model (modle de scurit pour SNMPv3 , bas sur password utilisateur) View based Access Control Model (sous systme de contrle daccs la MIB de lagent)

641

Technologies rseaux avances