1. Introduction (Einführung)

1. Introduction (Einführung)

1.1. Overview (Überblick)

Dieses Dokument beschreibt eine Architektur zur Beschreibung von SNMP-Management-Frameworks. Die Architektur ist modular gestaltet, um die Weiterentwicklung der SNMP-Protokollstandards im Laufe der Zeit zu ermöglichen.

Die Hauptteile der Architektur sind:

• Eine SNMP-Engine, die Dienste zum Senden und Empfangen von Nachrichten, zum Authentifizieren und Verschlüsseln von Nachrichten und zur Steuerung des Zugriffs auf verwaltete Objekte bereitstellt.

• Eine oder mehrere SNMP-Anwendungen, die die Dienste der SNMP-Engine nutzen, um spezifische Verwaltungsfunktionen auszuführen.

Die Architektur erlaubt die Verwendung verschiedener Nachrichtenformate und Sicherheitsmodelle. Sie ermöglicht die Weiterentwicklung von Sicherheitsprotokollen ohne größere Störungen bei SNMP-Implementierungen.

1.2. SNMP

SNMP ist ein Anwendungsschichtprotokoll zum Austausch von Verwaltungsinformationen zwischen Verwaltungssystemen und Agenten. SNMP wird weit verbreitet zur Verwaltung von Netzwerkgeräten wie Routern, Switches, Servern und Workstations verwendet.

Die erste Version von SNMP, bekannt als SNMPv1, wurde in den RFCs 1155, 1157 und 1212 definiert. SNMPv1 verwendet ein einfaches Sicherheitsmodell basierend auf Community-Strings.

Die zweite Version von SNMP, bekannt als SNMPv2c, wurde in den RFCs 1901-1908 definiert. SNMPv2c verwendet dasselbe Sicherheitsmodell wie SNMPv1, fügt aber neue Protokolloperationen und Datentypen hinzu.

Die dritte Version von SNMP, bekannt als SNMPv3, ist in den RFCs 3410-3418 definiert. SNMPv3 fügt SNMPv2c Sicherheits- und Fernkonfigurationsfähigkeiten hinzu. Dieses Dokument ist Teil des SNMPv3-Frameworks.

1.3. Goals of this Architecture (Ziele dieser Architektur)

Die Hauptziele dieser Architektur sind:

1. Modularität: Die Architektur ist so konzipiert, dass verschiedene Nachrichtenformate, Sicherheitsmodelle und Zugriffskontrollmodelle unabhängig voneinander verwendet werden können.

2. Evolution: Die Architektur ermöglicht das Hinzufügen neuer Funktionen, ohne Änderungen an bestehenden Implementierungen zu erfordern.

3. Sicherheit: Die Architektur bietet ein Framework zum Hinzufügen starker Sicherheit zu SNMP, einschließlich Authentifizierung, Vertraulichkeit und Zugriffskontrolle.

4. Koexistenz: Die Architektur ermöglicht es SNMPv1, SNMPv2c und SNMPv3, im selben Netzwerk zu koexistieren.

5. Einfachheit: Die Architektur ist so konzipiert, dass sie so einfach wie möglich ist und gleichzeitig die anderen Ziele erfüllt.

1.4. Security Requirements of this Architecture (Sicherheitsanforderungen dieser Architektur)

Die Architektur bietet Einrichtungen für die folgenden Sicherheitsdienste:

1. Datenintegrität: Stellt sicher, dass Nachrichten nicht auf unbefugte Weise verändert oder zerstört wurden. Dies wird durch die Verwendung von Nachrichtenauthentifizierungscodes erreicht.

2. Datenursprungsauthentifizierung: Bestätigt die Quelle einer Nachricht. Dies wird ebenfalls durch die Verwendung von Nachrichtenauthentifizierungscodes erreicht.

3. Nachrichtenwiedergabeschutz: Stellt sicher, dass jede Nachricht einzigartig ist und nicht zu einem späteren Zeitpunkt wiedergegeben werden kann. Dies wird durch die Verwendung von Zeitstempeln und Nachrichtenkennungen erreicht.

4. Datenvertraulichkeit: Schützt vor Offenlegung der Nachrichtennutzlast durch Verschlüsselung.

5. Zugriffskontrolle: Beschränkt den Zugriff auf verwaltete Objekte basierend auf der Identität des Benutzers und der Art der durchgeführten Operation.

Die Architektur adressiert auch die folgenden Sicherheitsbedrohungen:

• Maskerade: Eine nicht autorisierte Entität, die sich als autorisierte Entität ausgibt.

• Informationsänderung: Eine nicht autorisierte Entität, die Nachrichten während der Übertragung ändert.

• Nachrichtenstromänderung: Neuordnung, Verzögerung oder Wiedergabe von Nachrichten.

• Offenlegung: Freigabe von Nachrichteninhalten an eine nicht autorisierte Entität.

• Dienstverweigerung: Verhindern, dass autorisierte Benutzer auf das Verwaltungssystem zugreifen.

Die Architektur adressiert die folgenden Bedrohungen nicht:

• Verkehrsanalyse: Analyse von Nachrichtenmustern, um Informationen über das Netzwerk abzuleiten.

• **Dienstverweigerungsangriffe, die Ressourcen auf dem Agenten oder Manager verbrauchen.

1.5. Design Decisions (Entwurfsentscheidungen)

Bei der Entwicklung dieser Architektur wurden die folgenden Entwurfsentscheidungen getroffen:

1. Trennung der PDU-Verarbeitung von der Nachrichtenverarbeitung: Die Architektur trennt die Verarbeitung von Protocol Data Units (PDUs) von der Verarbeitung von Nachrichten. Dies ermöglicht die Verwendung verschiedener Nachrichtenformate mit demselben PDU-Format.

2. Mehrere Sicherheitsmodelle: Die Architektur ermöglicht die Koexistenz mehrerer Sicherheitsmodelle und erlaubt die Weiterentwicklung von Sicherheitsprotokollen.

3. Mehrere Zugriffskontrollmodelle: Die Architektur ermöglicht die Koexistenz mehrerer Zugriffskontrollmodelle und erlaubt verschiedene Zugriffskontrollrichtlinien.

4. Trennung von Authentifizierung und Vertraulichkeit: Die Architektur ermöglicht die unabhängige Verwendung von Authentifizierung und Vertraulichkeit. Dies erlaubt Authentifizierung ohne Vertraulichkeit, was in einigen Umgebungen erforderlich sein kann.

5. Verwendung abstrakter Service-Schnittstellen: Die Architektur definiert abstrakte Service-Schnittstellen zwischen den Hauptkomponenten. Dies ermöglicht die Interoperabilität verschiedener Implementierungen jeder Komponente.

6. Betonung der Fernkonfiguration: Die Architektur betont die Fähigkeit, Sicherheits- und Zugriffskontrollparameter fernzukonfigurieren. Dies ist für große Bereitstellungen unerlässlich.

7. Rückwärtskompatibilität: Die Architektur ist so konzipiert, dass dieselbe SNMP-Engine, die SNMPv3-Nachrichten verarbeitet, SNMPv1- und SNMPv2c-Nachrichten verarbeiten kann.

8. Vorwärtskompatibilität: Die Architektur ist so konzipiert, dass in Zukunft neue Nachrichtenformate und Sicherheitsmodelle hinzugefügt werden können.