Zusammenfassung

  • RFC 5343 nutzt localEngineID, um den lokalen Standardkontext zu erreichen und snmpEngineID.0 zu lesen. Der Sonderwert darf nicht als tatsächliche EngineID ausgegeben werden.
  • EngineID bezeichnet den Managementort; securityName bezeichnet den Principal. VACM entscheidet die View anhand von Sicherheitsmodell, Name, Niveau, contextName und Variable.
  • Gleicher Kontext bedeutet weder gleiche Authentisierung noch gleiche Berechtigung. Entdeckung, Zugriff und Wirkung brauchen getrennte Belege.

Der bekannte Wert beantwortete eine Bootstrapping-Frage

Eine SNMP-Entität kann mehrere Kontexte bedienen. Ein Objekt wird im administrativen Bereich durch contextEngineID, contextName, Objekttyp und Instanz bestimmt. Kennt ein Manager die EngineID noch nicht, fehlt ihm ausgerechnet ein Teil der Adresse, die er für die erste Anfrage braucht.

RFC 5343 reserviert dafür Format 6 unter Enterprise null und den Hexwert 8000000006. Ein kompatibler Responder registriert seine PDU-Typen unter diesem Selektor zusätzlich zur normalen EngineID. Der Selektor bezeichnet stets den lokalen Standardkontext des Empfängers.

Zuerst wird ein bekannter Wert verwendet, dann die Entdeckung des Security Models, sofern vorhanden, und zuletzt ein Read von snmpEngineID.0 unter localEngineID. Der Sonderwert darf weder selbst in snmpEngineID.0 noch als USM msgAuthoritativeEngineID erscheinen. Er ist eine standardisierte Frage, keine Antwort und kein Credential.

EngineID und securityName bleiben orthogonal

RFC 3411 definiert securityName als lesbare Repräsentation eines Principals. Das Security Model erzeugt ihn aus seiner eigenen Sicherheitsidentität und liefert das securityLevel. Die EngineID benennt dagegen eine Engine innerhalb eines administrativen Bereichs.

RFC 5343 stellt fest, dass isAccessAllowed() contextEngineID nicht als Eingabe erhält. VACM kann daher keine Sonderberechtigung aus dem Gebrauch von localEngineID ableiten. Es ordnet <securityModel, securityName> einer Gruppe zu und prüft contextName, Niveau, View-Typ und Variable.

Eine unauthentisierte und eine authentisierte Anfrage können denselben contextEngineID tragen und völlig unterschiedliche Autorität besitzen. Bei noAuthNoPriv ist securityName nicht kryptografisch bestätigt. Das Entdeckungsergebnis darf nicht als authentifizierte Geräteidentität gespeichert werden.

Beständigkeit über Transportwechsel ist beabsichtigt

contextEngineID kann als Ende-zu-Ende-Bezeichner dienen, wenn Proxy, Protokollübersetzung oder wechselnde Transportadresse dazwischenliegen. Der Managementkontext bleibt korrelierbar, gerade weil EngineID und Endpoint nicht zusammenfallen müssen.

Ein Unterschied ist deshalb ein Prüfhinweis, kein Beweis für Täuschung. Ebenso ist ein eingebetteter MAC- oder IP-Wert nur Konstruktionsmaterial. Er beweist keine aktuelle Schnittstelle, Route oder Eigentümerschaft.

Die Eindeutigkeit gilt im administrativen Bereich. Föderation kann Koordination verlangen. Wer den Bereich entfernt, macht aus einem lokalen Namensversprechen eine globale Geräte-ID.

Discovery kann Informationen offenlegen

EngineID-Formate können IPv4, IPv6, MAC, Text oder administrative Oktette enthalten. RFC 5343 warnt, dass eine Abfrage Informationen hinter Router, Firewall oder NAT sichtbar machen kann, und empfiehlt Schutz.

Gleichzeitig kann noAuthNoPriv-Lesbarkeit legitimen Werkzeugen nützen. Diese Abwägung muss als Policy erkennbar bleiben. RFC 5591 liefert später TSM-Kontext; seine Existenz beweist aber nicht, dass eine konkrete Nachricht geschützt war. Auch geschützter Transport ersetzt VACM nicht.

Der spätere SET braucht eigene Quittungen

Beim Discovery-Read dürfen weitere Variablen wie sysObjectID.0 mitgelesen werden. Weniger Roundtrips bedeuten nicht mehr Autorität. Ein späterer Schreibanspruch braucht den tatsächlichen Principal, VACM-Zulassung für die genaue Variable, PDU-Disposition, Read-back und gegebenenfalls eine externe Wirkungsbeobachtung.

Logs sollten Endpoint, Zeit, Security Model, securityName, Niveau, contextEngineID, contextName, OID, Request-ID und Resultat getrennt halten. Nur so bleibt sichtbar, ob Name, Zugriff oder Wirkung bewiesen wurden.

Das heutige Register ist keine historische Capability-Liste

RFC 5343 dokumentierte Formate 1–5, wies 6 dem lokalen Motor zu, ließ 128–255 unternehmensspezifisch und verlangte eine Spezifikation für neue kontrollierte Werte. Das aktuelle IANA-Register zeigt heutige Verwaltung.

Es beweist nicht, was ein alter Agent verstand oder ein aktuelles Produkt implementiert. Snapshot-Datum und gemessene Peer-Capability gehören zur Beobachtung. Registrierung koordiniert Syntax, nicht Frische, Datenschutz oder Laufzeiterfolg.

Quellen und Beweisgrenze

Die Quellen umfassen RFC 5343, SNMP-Architektur, Dispatch, USM, VACM, Operationen, MIB, späteres TSM, IANA und offengelegte Governance-Texte. Sie belegen kein benanntes Produkt, Deployment, offenes Gerät, unzulässigen Zugriff, erfolgreichen Schreibvorgang, Vorfall oder Verbreitungsgrad.