Zum Hauptinhalt springen

11.4. Use of Reports (Verwendung von Berichten)

11.4. Use of Reports (Verwendung von Berichten)​

Dieser Abschnitt beschreibt, wie USM den SNMP-Berichtsmechanismus (Report) verwendet, um Fehler und andere Informationen zu kommunizieren.

Report PDU (Berichts-PDU)​

Die in [RFC3416] definierte Berichts-PDU (Report PDU) wird von USM verwendet, um Informationen über Fehler zurückzugeben, die während der Nachrichtenverarbeitung aufgetreten sind. Berichte sind besonders wichtig für:

  1. Entdeckung (Discovery) - Rückgabe der snmpEngineID der autoritativen Engine
  2. Zeitsynchronisation (Time synchronization) - Rückgabe aktueller Engine-Zeitwerte
  3. Fehlerbenachrichtigung (Error notification) - Anzeige von Authentifizierungs-, Datenschutz- oder anderen sicherheitsbezogenen Fehlern

USM Statistics (USM-Statistiken)​

USM verwaltet mehrere Zähler, die verschiedene Fehlerbedingungen verfolgen. Diese Zähler sind in der usmStats-Gruppe des MIB-Moduls definiert (Abschnitt 5):

  • usmStatsUnsupportedSecLevels - Nachrichten mit nicht unterstützten Sicherheitsstufen
  • usmStatsNotInTimeWindows - Nachrichten außerhalb des Zeitfensters
  • usmStatsUnknownUserNames - Nachrichten mit unbekannten Benutzernamen
  • usmStatsUnknownEngineIDs - Nachrichten mit unbekannten Engine-IDs
  • usmStatsWrongDigests - Nachrichten mit falschen Authentifizierungs-Digests
  • usmStatsDecryptionErrors - Nachrichten mit Entschlüsselungsfehlern

Report Generation (Berichtsgenerierung)​

Wenn USM während der Verarbeitung eingehender Nachrichten einen Fehler erkennt, KANN (MAY) es einen Report-PDU generieren, der Folgendes enthält:

  1. Das entsprechende USM-Statistikzählerobjekt
  2. Den aktuellen Wert dieses Zählers
  3. Die relevante msgID aus der empfangenen Nachricht (zur Zuordnung)

Wichtige Überlegungen:

  • Berichte werden NICHT immer für jeden Fehler generiert. Die Entscheidung hängt von der Sicherheitsstufe und dem Fehlertyp ab.
  • Berichte für bestimmte Fehler (wie usmStatsNotInTimeWindows für die Entdeckung) werden konstruktiv verwendet.
  • Berichte DÜRFEN NICHT (MUST NOT) als Antwort auf einen anderen Bericht gesendet werden, um Endlosschleifen zu vermeiden.

Security Levels for Reports (Sicherheitsstufen für Berichte)​

Berichte werden je nach Fehler mit unterschiedlichen Sicherheitsstufen gesendet:

  1. noAuthNoPriv - Verwendet für:

    • Entdeckung (unbekannte engineID)
    • Zeitsynchronisationsfehler
    • Unbekannte Benutzernamen

  2. Gleich wie Anfrage - Verwendet für:

    • Authentifizierungsfehler (falscher Digest)
    • Entschlüsselungsfehler
    • Zeitfensterfehler (nach Synchronisation)

Report Reception (Berichtsempfang)​

Wenn ein Befehlsgenerator oder Benachrichtigungsinitiator einen Report-PDU empfängt:

  1. Entdeckungsantwort: Wenn der Bericht usmStatsUnknownEngineIDs enthält und das varBind eine Nicht-Null-engineID enthält, hat die Anwendung die Identität der autoritativen Engine erfolgreich entdeckt.

  2. Zeitsynchronisationsantwort: Wenn der Bericht usmStatsNotInTimeWindows enthält, sollte die Anwendung msgAuthoritativeEngineBoots und msgAuthoritativeEngineTime aus den securityParameters extrahieren und ihren lokalen Cache aktualisieren.

  3. Fehlerindikation: Bei anderen Berichtstypen sollte die Anwendung den Bericht als Hinweis darauf behandeln, dass die ursprüngliche Anfrage aus dem angegebenen Grund fehlgeschlagen ist.

Report Handling Best Practices (Bewährte Praktiken für die Berichtsbehandlung)​

  1. Berichtsstürme vermeiden: Implementierungen sollten die Berichtsgenerierung ratenbegrenzen oder unterdrücken, um Netzwerküberlastung zu verhindern.

  2. Berichte protokollieren: Sicherheitsbezogene Berichte sollten für Audit- und Sicherheitsanalysen protokolliert werden.

  3. Benutzerfeedback: Anwendungen sollten den Benutzern klares Feedback geben, wenn Berichte auf Authentifizierungs- oder Autorisierungsfehler hinweisen.

  4. Zeitfensterfehler: Nach mehreren usmStatsNotInTimeWindows-Berichten sollten Implementierungen Uhrenabweichungen vermuten und möglicherweise manuelle Eingriffe erfordern.

Privacy and Reports (Datenschutz und Berichte)​

Berichte, die als Antwort auf Nachrichten mit Datenschutz generiert werden, erfordern möglicherweise spezielle Behandlung:

  • Wenn die Entschlüsselung fehlschlägt, sollte der Bericht usmStatsDecryptionErrors anzeigen.
  • Der Bericht selbst sollte, wenn möglich, mit derselben Sicherheitsstufe wie in der ursprünglichen Nachricht angefordert gesendet werden.
  • Wenn die Sicherheitsstufe nicht bestimmt werden kann (z.B. aufgrund schwerer Nachrichtenbeschädigung), sollte der Bericht mit noAuthNoPriv gesendet werden.
Letztes Update am