Herstelleruebergreifendes Netz-Management, bis vor wenigen Jahren ein frommer Anwenderwunsch, ist inzwischen zur Realitaet geworden. Eine der Ursachen fuer diese Entwicklung ist sicherlich das Simple Network Management Protocol (SNMP). Das Protokoll, ein pragmatischer Internet-Ansatz, loest zwar bei weitem nicht alle Probleme, die ein Anwender heute in heterogenen Netzen hat, liefert aber doch einen wichtigen Beitrag zur Schaffung von praktikablen Loesungen. Wolfgang Schott* und Rainer Janssen* erlaeutern in ihrem Beitrag Version 2 des SNMP-Protokolls, die sich in ihrer Konzeption etwas den OSI-Management- Verfahren annaehert, wobei eine Migration von den Autoren aber bezweifelt wird.

Die Grundidee fuer das Management heterogener Umgebungen besteht in der Modellierung der realen Netzkomponenten in Form von Managed Objects, die durch Management-Stationen ueberwacht und gesteuert werden. Zur Unterstuetzung des Managements tauschen diese Stationen und Komponenten Nachrichten mit Hilfe eines Protokolls aus. Damit die Management-Stationen auch wissen, welche Informationen sie von einem bestimmten Komponententyp (Bridge, Router) erwarten koennen, werden deren Eigenschaften in den sogenannten Management Information Bases (MIBs) beschrieben.

In den letzten Jahren konnte das im Internet-Umfeld entstandene SNMP einen beachtlichen Erfolg als Instrument fuer herstelleruebergreifendes Netz-Management verzeichnen. Einer der Gruende dafuer ist die Unkompliziertheit (simple) des Protokolls. Es erlaubt, Agenten, die das Management von Komponenten ueberhaupt erst ermoeglichen, mit relativ geringem Aufwand in der Netzkomponente zu implementieren. Einige der in SNMP realisierten Konzepte haben sich in der Praxis aber dann doch als zu "simple" herausgestellt und zur Notwendigkeit der Weiterentwicklung in Form von SNMP, Version 2 (SNMPv2), gefuehrt.

SNMPv2 soll Maengel der ersten Fassung ausmerzen

SNMPv2 entstand als Antwort auf eine Maengelliste zu SNMPv1, die sich aus dem umfangreichen praktischen Einsatz des De-facto- Standards ergeben hatte. Ende 1992 existierten zu SNMPv2 zunaechst drei Request-for-Comment-Dokumente (RFC): RFC 1351 SNMP Administrative Model, RFC 1352 SNMP Security Protocols und RFC 1353 Defini- tions of Managed Objects of SNMP Parties sowie eine Reihe von nicht numerierten Entwuerfen. Diese wurden dann im April 1993 durch eine Serie von zwoelf neuen Dokumenten (RFC 1441 bis RFC 1452) ersetzt, die als Basis fuer den endgueltigen Standard dienen werden und zur Zeit den Status eines Proposed-Standard besitzen.

Die Neuerungen in SNMPv2 beziehen sich auf folgende, hier der Reihe nach zu eroerternde Themen:

- Kommunikationsmodell fuer SNMP-Protocol-Entities,

- Sicherheitskonzepte,

- Kommunikation zwischen Management-Stationen,

- Erweiterung des Agent-Konzeptes,

- Einfuehrung einer MIB fuer SNMP-Protocol-Entities,

- Uebertragung groesserer Informationsmengen in einer Protokolldateneinheit (Protocol Data Unit = PDU),

- erweiterte Fehlersignalisierung und Traps,

- Erweiterungen zur Structure of Management Information (SMI) sowie

- Verwendung unterschiedlicher Transportdienste.

Kommunikationsmodell: In SNMPv1 werden die Kommunikationsbeziehungen zwischen Management-Stationen und Agents durch deren Zugehoerigkeit zu Gruppen (Communities) definiert, die eindeutige Gruppenbezeichner (Community Names) besitzen. In SNMPv2 wird dieses Modell durch die Einfuehrung der "SNMPv2 Party" und des "SNMPv2 Context" (RFC 1445: Administrative Model for SNMPv2) wesentlich erweitert (vgl. Abbildung 1).

SNMPv2 Party ist eine Ablaufumgebung fuer SNMP-Operationen, in der eine definierte Menge von Parametern die Randbedingungen fuer die Generierung und Verarbeitung von SNMP-Nachrichten in einer SNMP- Entity festlegt. Anders ausgedrueckt: Die Arbeitsweise einer SNMP- Entity wird durch die Regeln der Party, mit der sie momentan arbeitet, gesteuert. Die Wirkung einer Party bezieht sich, entsprechend dem Grundkonzept von SNMP, jeweils nur auf eine SNMP- Nachricht.

Die Parameter einer Party beschreiben:

- einen global eindeutigen Namen fuer die Party,

- ein Authentikationsprotokoll, ueber das sich die sendende Party gegenueber der empfangenden ausweist,

- ein Verschluesselungsprotokoll, das die SNMP-Nachrichten, die ueber diese Party gesendet oder empfangen werden, verschluesselt sowie

- das Transportprotokoll, ueber das diese Party arbeitet.

In jeder SNMP-Nachricht, die zwischen zwei SNMP-Entities ausgetauscht wird, muss nun der Name der verwendeten Party auf der Quell- und auf der Ziel-Entity angegeben werden, damit die empfangende Entity ueberhaupt in der Lage ist, die ankommende Nachricht zu erkennen und zu entschluesseln.

Saemtliche Party-Parameter sind wie Parameter von Managed Objects in einer eigenen MIB abgebildet, wodurch die Parties ihrerseits zu Managed Objects werden (RFC 1447: Party MIB fuer SNMPv2).

Der zweite wesentliche Begriff im Kommunikationsmodell von SNMPv2 ist der des "SNMPv2 Context". Ein solcher Context definiert eine Sicht auf das Objektmodell einer SNMPv2-Entity. Diese Sicht besteht aus einer beliebigen Menge von Ausschnitten einer oder mehrerer MIBs und wird auch "MIB View" genannt. Alle nicht in einem Context enthaltenen Variablen bleiben unsichtbar und sind ueber SNMP-Operationen nicht les- oder veraenderbar. So wie die verwendete Party muss auch der verwendete Context in jeder SNMPv2- Nachricht angegeben werden und bei beiden beteiligten Entities bekannt sein (vgl. Abbildung 2).

Parties und Contexts sind prinzipiell voneinander unabhaengig. Es sind jedoch fuer jede Party die Zugriffsrechte auf jeden lokal bekannten Context individuell definierbar. Mit diesem Konzept ist es moeglich, zum Beispiel auf einem einzigen Agent - abhaengig vom verwendeten Context - voellig unterschiedliche und fein granulierbare Zugriffsmoeglichkeiten und Privilegien festzulegen.

Sicherheitskonzept: Einer der staendigen Kritikpunkte an SNMPv1 waren die nur unzureichend ausgepraegten Sicherheitsmechanismen. Sie mussten sich auf die Verwendung von Community Names beschraenken, die im Klartext ueber das Netz uebertragen werden. Die Schwaeche des Sicherheitskonzeptes lag also darin, dass es sich weitgehend auf die Authentikation einer Protokollnachricht beschraenkte, weitere Aspekte aber nicht beruecksichtigte.

Deshalb wurden fuer das Sicherheitskonzept in SNMPv2 (RFC 1446: Security Protocols for SNMPv2) folgende vier Ziele definiert :

- die Nachpruefbarkeit des Nachrichtenursprungs (Origin Authentication),

- die Nachrichtenintegritaet (Message Integrity),

- der Schutz vor Wiederholungen (Replay Protection) sowie

- die Vertraulichkeit einer Nachricht (Privacy).

Zusaetzlich sollten die konkret verwendeten Sicherheitsmassnahmen vom Netz-Manager von einer trivialen bis zur maximalen Sicherheitsstufe konfigurierbar sein.

Zur Erreichung dieser Ziele benutzt SNMPv2 zwei Verfahren: ein Authentikationsprotokoll (Digest Authentication Protocol) und ein Datenverschluesselungsprotokoll (Symmetric Privacy Protocol).

Als Authentikationsmechanismus kommt der MD5-Algorithmus (RFC 1321) zum Einsatz, der als eine Art elektronische Unterschrift die 128 Bit lange Pruefsumme zu einer PDU berechnet, wobei ein geheimer, 16 Oktette langer Schluessel verwendet wird. Die Pruefsumme wird zusaetzlich zur PDU uebertragen. Als Verschluesselungsverfahren wird der DES-Algorithmus (Data Encryption Standard) verwendet, der mit einem 16 Oktette langen, geheimen Schluessel arbeitet.

Die Cocom-Liste erzeugt Verschluesselungsprobleme

Ein Nachteil des DES-Verfahrens (wie auch des MD5) liegt allerdings darin, dass Software, die diese Algorithmen implementiert, noch immer nur unter starken Einschraenkungen Cocom- Liste aus den USA exportiert werden darf, eine Klaerung dieser Situation steht noch aus. Dies ist einer der Gruende dafuer, dass die Authentikation und die Verschluesselung von SNMP-PDUs in SNMPv2 optional sind.

Es ist eine besondere Leistung der SNMPv2-Architekten, dass sich durch den Einsatz dieser beiden Verfahren der Aufbau einer SNMP- Nachricht gegenueber Version 1 nicht veraendert: Sie besteht aus Version, Community Name und der als "Data" bezeichneten SNMP- Protokolldateneinheit (SNMP-PDU).

In SNMPv2 (RFC 1446: Security Protocols for SNMPv2) wird die PDU nun um die Angabe von Quell-Party und Ziel-Party samt Context erweitert und diese Struktur mit der Authentikationsinformation ergaenzt (vgl. Abbildung 3). Ueber die gesamte Information wird die MD5-Pruefsumme berechnet, es entsteht die gesicherte Authentikationsinformation. Diese kann nun optional ueber DES verschluesselt werden und bildet zusammen mit dem Namen der Ziel- Party die "SnmpPrivMsg", die in der SNMPv2-Nachricht als "Data" uebertragen wird.

Sicherheitsaspekte: Da RFC-Standards im Gegensatz zu ISO-Standards vor ihrer Verabschiedung in Pilotprojekten implementiert werden muessen, liegen bereits Erfahrungen mit den beschriebenen Sicherheitskonzepten vor. So erhoeht die Implementierung des MD5- Algorithmus den Verarbeitungsaufwand fuer SNMP-Protokollnachrichten um rund 15 bis 20 Prozent, die Anwendung des DES-Algorithmus zum Erzielen einer hohen Sicherheit hat also auch hier ihren Preis. Geht man allerdings davon aus, dass die DES-Verschluesselung nur fuer den Austausch vertrau- licher Informationen aktiviert wird und MD5-Authentikation nur fuer SET-Requests, dann faellt diese Erhoehung des Verarbeitungsaufwandes kaum ins Gewicht. Fuer den Umfang eines SNMPv2-Agent sind Groessenordnungen von etwa 40 KB Code zu erwarten

Manager-to-Manager-MIB definiert Alarmmeldungen

Kommunikation zwischen Management-Stationen: Die Kommunikation zwischen Management-Stationen ist immer dann notwendig, wenn hierarchische Management-Konzepte implementiert werden sollen. Die Notwendigkeit hierarchischer Konzepte ergibt sich aus der Tatsache, dass in vielen Faellen ein einziges Produkt als Management-Station nicht zur Loesung aller Anforderungen geeignet ist und daher mehrere Erzeugnisse eingesetzt werden, die aber im Sinne einer Gesamtloesung zu integrieren sind. Die dazu notwendige Kommunikation zwischen Management-Stationen wurde in SNMPv1 nicht unterstuetzt.

SNMPv2 fuehrt nun ein neues Modell ein, in dem auf einer Management-Station Alarme und Ereignisse definiert werden koennen, deren Auftreten dann das Senden spontaner Meldungen an eine andere Management-Station ausloest (RFC 1452: Manager-to-Manager- Information-Base). Dieses Modell erinnert sehr stark an das des Remote Network Monitoring (RMON).

Das Modell ist einfach: Fuer eine beliebige Objektvariable, die durch zyklisches Pollen ueberwacht wird, definiert man einen oberen und einen unteren Schwellwert. Ueber- oder unterschreitet diesen der Variablenwert (Alarmbedingung), loest dies ein Ereignis (Event) aus, das wiederum mit dem Senden einer oder mehrerer spontaner Meldungen (Notifications) verknuepft ist. Diese Notifications sind aber keine Traps, sondern werden in Form einer neu eingefuehrten SNMP-Operation, "inform-request", gesendet, die nur zwischen Management-Stationen zur Anwendung kommt.

In diesem Modell arbeitet eine SNMP- Application-Entity in zwei Rollen: Zur Erfassung der Variablenwerte von den Managed Nodes verhaelt sie sich als Manager, bei der Alarmueberwachung und beim Senden der Notifica- tions operiert sie als Agent. Die Beschreibungen von Alarmen und Ereignissen und deren Verknuepfungen mit Notifications sind in einer eigenen MIB, der Manager-to- Manager-MIB, abgelegt, die den Alarm- und Ereignistabellen der RMON-MIB stark aehneln.

Erweiterung des Agent-Konzeptes: Die Doppelrolle der SNMP-Entities fuehrte ebenfalls zu Ueberlegungen, wie ein Agent besser an diese neue Situation angepasst werden kann. So wie der Manager-Teil der Entity nun Informationen an einen uebergeordneten Manager weiterleiten muss, ist es Aufgabe des Agent-Teils, von unterlagerten Stationen Informationen "einzusammeln".

SNMPv2 erlaubt nun die Definition von Haupt- und spezialisierten Sub-Agentsen, wobei jedem Sub-Agentsen ein unterschiedlicher SNMPv2-Context zugewiesen werden kann. Die Sub-Agentsen koennen entweder zusammen mit dem Haupt-Agent auf einer Station residieren oder auf anderen Stationen lokalisiert sein. Ihre Namen und Parameter werden in der Object Resource Group der SNMPv2-MIB eingetragen (vgl. Abbildung 4).

MIB fuer SNMP-Protocol-Entities: Mit der Einfuehrung der SNMP- Parties werden die SNMP-Protocol-Entities zu kritischen Ressourcen im SNMP-Management, und der Gedanke liegt nahe, sie wie Netzkomponenten ebenfalls zu ueberwachen und zu steuern. Die Basis dazu wird mit der SNMPv2-MIB (RFC1450: Management Information Base for SNMPv2) gelegt.

Uebertragung groesserer Datenmengen in einer PDU (Get-bulk): SNMPv1 verwendet zum Auslesen von Objektvariablen die Get- und Get-next- Operation, wobei Get-next insbesondere fuer das sequentielle und dynamische Auslesen von Tabellen gedacht ist.

Im praktischen Betrieb stellte sich jedoch bald heraus, dass die Verwendung von Get-next beim Auslesen grosser Tabellen (wobei jeweils nur ein Element pro Leseoperation uebertragen wird) zu starken Belastungen des Netzes durch das Netz-Management fuehrt und damit den fundamentalen Forderungen der SNMP-Architektur widerspricht.

Die in SNMPv2 neu eingefuehrte Get-bulk-Operation ist konzeptuell nichts Neues, sie basiert auf einer wiederholt ausgefuehrten Get- next-Operation. Die Wiederholung geschieht aber im Agent, und die Ergebnisse werden nicht in viele einzelne, sondern in eine grosse Antwort gepackt.

Die Implementierung von Get-bulk hat, wie die Pilotimplementierungen zeigen, einen dramatischen Effekt auf die Performance von Tabellenabfragen - es wurden Verbesserungen um den Faktor zehn gegenueber Get-next beobachtet.

Fehlersignalisierung bei Get, Get-next und Set: In SNMPv2 wird der unbefriedigende Zustand behoben, dass bei Auftreten eines Fehler waehrend der Bearbeitung einer Get-, Get-next- oder Set-Operation nur ein zusammenfassender Fehlerstatus gemeldet und die Operation abgebrochen wird. Statt dessen meldet der SNMPv2-Agent variablenbezogene Fehlerkennungen - zum Beispiel "noSuchObjekt" oder "noSuchInstance" - und liest beziehungsweise setzt die korrekt angegebenen Variablen.

Traps: Das Grundkonzept von SNMP ist das Polling, das heisst, die Aktivitaet geht immer von der Management-Station aus, die sich ueber das Befinden einer Netzkomponente informieren moechte. In bestimmten Situationen kann es sinnvoll sein, einer Netzkomponente zu erlauben, eine Meldung an die Management-Station zu schicken, ohne dieser vorher das Eintreten eines Ereignisses zu signalisieren (Cold Start, Link Down etc.). Diese ereignisgesteuerten Meldungen werden Traps genannt.

Die Kritik an Traps in SNMPv1 bezog sich darauf, dass ihr Standard- Informationsgehalt gering ist, die Angabe von Variablenwerten der Implementierung ueberlassen bleibt und auch der Empfaenger von Traps implementierungsspezifisch festgelegt wird.

In SNMPv2 werden nun die Trap-Strukturen formal in der SNMPv2-MIB in Form von Notification-Type-Makros festgelegt. Diese Makros definieren zum Beispiel die in der Trap-Nachricht enthaltenen Variablenwerte. Andere Informationen, wie etwa ueber den Empfaenger der Trap, werden bei deren Generierung teils aus der Party-MIB, teils aus der SNMPv2-MIB entnommen.

Erweiterungen zur Structure of Management Information (SMI): In SNMPv2 werden die Moeglichkeiten zur formalen Beschreibung gegenueber Version 1 betraechtlich erweitert. Die Beschreibungsmittel dazu sind in den drei Dokumenten

- RFC1442 (Structure of Management Information for SNMPv2),

- RFC1443 (Textual Conventions for SNMPv2) sowie

- RFC1444 (Conformance Statements for SNMPv2) festgelegt.

Verwendung unterschiedlicher Transportdienste: Waehrend in SNMPv1 das User Datagram Protocol (UDP), ein verbindungsloses Protokoll, als einziger Transportdienst spezifiziert und die Verwendung weiterer Dienste als Moeglichkeit erwaehnt wurde, definiert SNMPv2 zunaechst vier Transportdienste mit den entsprechenden Mappings (RFC1449: Transport Mappings for SNMPv2). Dies sind

- UDP, OSI Connectionless Trans- port Service (CLTS), Appletalk DDP sowie Novell IPX.

Allerdings wird SNMP ueber UDP weiterhin als Preferred Transport Mapping herausgehoben.

Die Frage des Uebergangs von SNMpv1 auf SNMPv2 beziehungsweise der Koexistenz beider Protokolle haben sich auch die Autoren des SNMPv2- Framework gestellt und dazu das "RFC1452: Coexistence between version 1 and version 2 of the Internet-Standard Network Management" Framework verfasst.

Das Dokument schlaegt zwei Loesungen vor: die Proxy-Agent-Loesung und die Zweisprachigkeit (Bi-lingual Behavior).

Die Proxy-Agent-Loesung ist in Abbildung 5 dargestellt. Die Kommunikation mit den SNMPv1-Agents laeuft hier ueber einen zusaetzlichen Proxy-Agent, der die SNMP-Nachrichten umsetzt. Die Realisierung ist nicht allzu aufwendig, da das SNMPv2-Protokoll eine Uebermenge von SNMPv1 darstellt und im wesentlichen die Get- bulk-Kommandos in Get-next-Kommandos umwandelt, wobei die Traps konvertiert werden muessen.

In der zweisprachigen Loesung (vgl. Abbildung 6) beherrscht die Management-Station beide Varianten von SNMP und spricht mit jedem Agent in seiner Protokollversion. Diese Methode erfordert einen hoeheren Software-Aufwand. Dadurch wird die Existenz zahlreicher zweisprachiger Agents neben zweisprachigen Management-Stationen unwahrscheinlich.

Bei einem Uebergang von SNMPv1 zu SNMPv2 muessen natuerlich auch die MIB-Definitionen nach SNMPv2 uebersetzt werden. Das Coexistence- Dokument gibt hierzu einige Hinweise, und man kann davon ausgehen, dass ein Grossteil dieser Konvertierung sogar automatisch durchfuehrbar ist.

Was wird die Zukunft bringen? Es wurde bereits erwaehnt, dass parallel zur Entwicklung von SNMPv2 schon einige Pilotimplementierungen durchgefuehrt wurden. Inzwischen hat eine Reihe von Unternehmen, insbesondere im Bereich der portablen SNMP- Software, SNMPv2 realisiert. Es ist davon auszugehen, dass im Laufe des naechsten Jahres Anbieter von Management-Stationen und Hersteller von Netzkomponenten den Uebergang zu Version 2 vornehmen werden. Ein kritischer Aspekt fuer den Erfolg von SNMPv2 wird die Lizenzpolitik der Anbieter sein.

SNMP ist ein Paradebeispiel fuer das Vorgehen im Internet-Umfeld, denn man hat es geschafft, mit einem pragmatischen Ansatz, der die schnelle Implementierung und notwendige Unterstuetzung durch die Hersteller von Netzkomponenten erlaubt, den Markt zu erobern. Im zweiten Schritt wird dann eine Weiterentwicklung vorgenommen, die zum grossen Teil nicht notwendig gewesen waere, wenn man gleich die OSI-Management-Verfahren Common Management Information Service (CMIS) und Common Management Information Protocol (CMIP) inklusive Informationsmodell eingesetzt haette. Diese beinhalten viele der Features, die jetzt bei SNMP erst in der zweiten Version geliefert werden. Die Entwickler der OSI-Standards haben also von vornherein weitergedacht, der Markt hat aber einen anderen Weg eingeschlagen. Auch im Vergleich zu SNMPv2 haben die OSI-Management-Verfahren noch immer konzeptionelle Vorteile (zum Beispiel in ihrem Informationsmodell).

Die grosse Anzahl von MIBs im SNMP-Umfeld sollte nicht als ein Vorteil von SNMP interpretiert werden, sondern muss eher als Schwaeche des zugrundeliegenden Informationsmodells verstanden werden (keine Trennung zwischen Objekten und Attributen, keine Vererbung etc.). Es darf aber inzwischen stark bezweifelt werden, ob jemals eine direkte Migration von SNMP zu CMIS und CMIP stattfinden wird. Wahrscheinlicher ist eine staendige schrittweise Weiterentwicklung von SNMP und die Orientierung an allgemeinen Aktivitaeten zur Unterstuetzung echter objektorientierter Konzepte im Sinne von OSF/DME und der OMG.