Zusammenfassung

  • RFC 2012 definierte tcpConnState als read-write. Die Managementstation durfte ausschließlich deleteTCB(12) setzen; dies löschte den TCB der gewählten Verbindung und beendete sie auf dem verwalteten Knoten sofort.
  • Verbindungstabelle und TCP-Zähler belegten jeweils begrenzte Zustände und Mengen, aber keine durchgehende Kausalität von Bediener, Autorisierung und Absicht bis zu Anwendung, Gegenstelle und Dienst.
  • RFC 4022 behielt die Löschfunktion bei, ergänzte Adresstypen, getrennte Listener und Prozesszuordnung, machte Schreibzugriff optional und benannte unberechtigte Terminierung als Denial-of-Service-Risiko.

Eine Zeile mit zwei Rollen

Die TCP-MIB von 1996 liest sich zunächst wie ein Instrumentenbrett. Sie enthält Retransmission-Algorithmus und Zeitgrenzen, Verbindungslimit, aktive und passive Öffnungen, fehlgeschlagene Versuche, Resets etablierter Verbindungen, aktuelle Verbindungen sowie Segment-, Fehler- und RST-Zähler. In tcpConnTable wird eine Verbindung durch lokale und entfernte IPv4-Adresse samt Ports bestimmt.

tcpConnState konnte jedoch mehr als berichten. MAX-ACCESS read-write erlaubte genau eine Management-Schreiboperation: deleteTCB(12). Andere Zustandswerte durfte eine Station nicht setzen. Die erlaubte Operation löschte den Transmission Control Block auf dem Knoten und terminierte die Verbindung unmittelbar.

Ein RST zur Gegenstelle blieb implementierungsspezifisch; selbst ein gesendeter RST war nicht zuverlässig. Lokales Ende, Benachrichtigung der Gegenstelle, Wahrnehmung der entfernten Anwendung und Nutzerwirkung sind deshalb getrennte Ereignisse. Die Antwort des Agenten belegt sie nicht gemeinsam.

Gelöscht wurde das Gedächtnis der Verbindung

RFC 793 verortet im TCB lokale und entfernte Sockets, Sicherheits- und Prioritätsangaben, Zeiger auf Sende- und Empfangspuffer, Retransmission Queue, aktuelles Segment und Sequenzvariablen. CLOSED heißt dort fiktiv, weil ohne TCB keine Verbindung besteht.

Die Managementoperation änderte also kein Etikett. Sie entfernte den lokalen Protokollzustand. Die Tabellenzeile enthielt aber weder Aktionskennung noch Ticket, Grund, menschlichen Initiator, Anwendungsverantwortlichen oder dauerhaften Vorher-nachher-Beleg. Nach dem Ende verschwand die transiente Zeile; ein Vier-Tupel konnte später wieder auftauchen.

Die Fähigkeit stammte aus RFC 1213. Bereits 1991 erklärte dessen Änderungsliste, tcpConnState sei zur Löschung eines TCB read-write geworden. RFC 2012 überführte die gleichen Objekte in SMIv2. Authentisierung, Autorisierung, Zugriffskontrolle und Vertraulichkeit ordnete die Einleitung dem administrativen Rahmen zu; die eigene Security-Considerations-Sektion diskutierte sie nicht.

Aggregierte Bewegung ist keine Ursachenangabe

Nach einem Eingriff könnte tcpCurrEstab sinken, tcpEstabResets steigen oder ein zusätzlicher RST gezählt werden. Jeder Wert hat einen engeren Nenner: aktueller Bestand, bestimmte Übergänge nach CLOSED oder gesendete Segmente mit RST. Keiner bezeichnet einen Managementbefehl oder dessen Autor.

Eine belastbare Zuordnung muss die gelesene Zeile und Zeit, authentisierte Anfrage, aktuellen Sicherheitsnamen und menschliche Rolle, Kontext und Write View für diese Instanz, dokumentierten Grund, Agentenantwort, lokales Verschwinden, Anwendungsreaktion, Gegenstellenbeobachtung, Wiederholungen, Dauer und Dienstwirkung verbinden. Eine passende Zählerbewegung ist nur vereinbar mit der Handlung, nicht ihr Beweis.

Der Nachfolger machte Identität genauer und Capability kleiner

RFC 4022 verwarf die alte Tabelle, weil sie IPv4-spezifisch war und Listener mit Verbindungen vermischte. Die neue Tabelle indiziert beide Enden durch InetAddressType, Adresse und Port. RFC 4001 ergänzt Zonenindizes, wenn Adressen auf mehreren Geltungsbereichen nicht eindeutig sind. Eine eigene Listener-Tabelle unterscheidet Wildcard-, Familien- und adressgebundene Endpunkte.

Verbindungen und Listener können außerdem eine Betriebssystem-Prozess-ID ausweisen und so mit Host- oder Applikations-MIBs korreliert werden. Das verbessert „welcher Socket, welcher Prozess?“, nicht automatisch „welcher Mensch, welche Freigabe, welches Geschäftsergebnis?“. Eine PID kann null, wiederverwendet oder nur lokal interpretierbar sein.

tcpConnectionState behielt deleteTCB(12). Doch die Compliance-Erklärung gestattet MIN-ACCESS read-only und sagt ausdrücklich, dass Schreibzugriff und deleteTCB-Unterstützung nicht erforderlich sind. Modulkonformität beweist daher nicht den Trennschalter; Capability beweist nicht Berechtigung; Berechtigung beweist nicht Ausführung.

RFC 4022 benennt den Sicherheitsfall erstmals deutlich: Unberechtigter Schreibzugriff kann eine beliebige Verbindung beenden und Denial of Service verursachen. Auch lesbare Verbindungs-, Listener- und Prozessdaten können sensibel sein.

Ein sicherer Request ist noch kein vollständiger Beleg

RFC 3414 bindet eine SNMPv3-Nachricht an einen Benutzer, schützt Integrität und Zeitnähe und kann Vertraulichkeit liefern. RFC 3415 trennt Read-, Write- und Notify-Views anhand von Sicherheitsmodell, Name, Niveau, Kontext und Objektinstanz.

Das schließt wichtige Lücken bis zum Agenten. Es erzeugt aber kein Ticket, keinen Betriebsgrund, keine Applikationsbestätigung, keine Empfangsquittung der Gegenstelle, keine Kundenauswirkung und keine Dauer. Zudem authentisiert USM den Benutzer, in dessen Namen eine Nachricht entstand, nicht zwingend die konkrete Person.

Ein Notfallhebel kann legitim sein. Die historische Warnung lautet, Beobachtung, Freigabe, Handlung und Wirkungsnachweis nicht zu einem grünen Status zu verschmelzen. Die Spezifikation beschreibt den Hebel; die laufenden Systeme tragen die Folge.

Quellen

Evidenzgrenzen

Die Quellen belegen Dokumente, Objekte, Compliance und Sicherheitsmodelle. Sie belegen keinen Anbieter-Support, keinen realen Einsatz, keinen Vorfall, keine Verbreitung, keinen SLA-Verstoß und keine heutige Standardkonfiguration.