Zusammenfassung

  • RFC 1419 transportierte unveränderte SNMP-Nachrichten über AppleTalk DDP, damit auch Netzkomponenten ohne TCP/IP verwaltet werden konnten. Anfragen liefen über Socket 8, Traps über Socket 9, jeweils mit Protokolltyp 8.
  • Der beständigere NBP-Name bezeichnete den gewünschten Dienst, die veränderliche DDP-Adresse dessen gegenwärtigen Weg. Eine über Neustarts erhaltene Zuordnung sparte Suchen und konnte direkte Verwaltung trotz eines Ausfalls der Namensauflösung ermöglichen.
  • Der Cache war kein Identitätsnachweis. Ein neuer Knoten konnte die alte Adresse erhalten und auf einen SET formal korrekt antworten. Erreichbarkeit, Namensbehauptung, Authentisierung, Berechtigung und tatsächliche Gerätewirkung blieben getrennte Tatsachen.

Eine andere Hülle, keine andere Managementsprache

RFC 1419 erschien im März 1993 für ein heterogenes Netz. Manche verwaltbaren Elemente beherrschten AppleTalk, aber kein TCP/IP. Hätte ein einheitliches Management zunächst einen IP-Stack verlangt, wäre Beobachtbarkeit an eine technische Migration der beobachteten Geräte gebunden gewesen.

Stattdessen definierte das Dokument eine schmale Transportabbildung. Die codierte SNMP-Nachricht kam in den Datenteil eines DDP-Datagramms. RFC 1157 bot dafür Raum: SNMP-Nachrichten waren in sich geschlossene Datagramme; andere vernünftige Transportdienste konnten verwendet werden, wenn ihre Transportadressen festgelegt waren. GetRequest, GetNextRequest, GetResponse, SetRequest und Trap behielten ihre Bedeutung.

DDP adressierte Netz, Knoten und Socket und führte zusätzlich einen Protokolltyp. Sein Datenfeld fasste höchstens 586 Oktette. Eine SNMP-Anfrage ging an Socket 8 mit Typ 8. Die Antwort kehrte zum Ursprungssocket zurück, ebenfalls mit Typ 8; ihre Quelladresse entsprach dem Ziel, an das die Station die Anfrage geschickt hatte.

Traps verwendeten Socket 9. Darin steckte mehr als Portkonvention. Bei einer Anfrage stand der Rückweg bereits im empfangenen Umschlag. Ein unaufgeforderter Trap brauchte dagegen einen zuvor bestimmten Empfänger. Eine Antwort vom erwarteten DDP-Tupel belegte den Paketweg, nicht die dauerhafte Identität des Geräts oder die Autorität des Bedieners.

Verfügte ein Element über mehrere Stacks und war UDP nutzbar, bevorzugte RFC 1419 weiterhin UDP. AppleTalk war eine zusätzliche Straße für vorhandene Systeme, kein Anspruch, das Management auf diesen Transport zu vereinheitlichen.

Der Name bezeichnete die Absicht, die Adresse nur den nächsten Weg

NBP stellte Dienste als object:type@zone dar. Die Bestandteile waren ohne Beachtung der Groß- und Kleinschreibung zu vergleichen, meist lesbar und auf je 32 Oktette begrenzt. Ein Agent registrierte SNMP Agent; eine Station für Traps kündigte SNMP Trap Handler an.

Der Objektteil sollte sich an dem Namen orientieren, unter dem das Netz die Maschine bereits kannte. Für Macintosh-Systeme verwies der Text auf den Macintosh Name von System 7. Der Managementdienst blieb dadurch mit der betrieblichen Kontinuität des Systems verbunden, statt eine unabhängige Bezeichnung zu erfinden.

Diese Bindung war keine kryptografische Identität. Eine AppleTalk-Adresse konnte sich bei jedem Neustart oder noch häufiger ändern. Der NBP-Name sollte dagegen in stabilem Speicher liegen und höchstens so oft wechseln wie die Adresse eines typischen TCP/IP-Hosts.

Damit entstanden zwei Zeitachsen. Der Name hielt fest, welchen Dienst die Station verwalten wollte. Die Zuordnung lieferte Netz, Knoten und Socket, unter denen er momentan erreichbar schien. Jeder Implementierer der Abbildung musste NBP-Suchen und -Bestätigungen beantworten. Das schuf einen verlässlichen Vorgang zur Ermittlung, aber weder eine unbefristete Gültigkeit noch eine signierte Antwort.

Ein persistenter Cache konnte den Ausfall seiner Quelle überbrücken

NBP-Suchen verbrauchten Bandbreite und Rechenzeit. Noch wichtiger: Sie konnten ausfallen, obwohl direkte DDP-Kommunikation weiterlief. Widersprüchliche Zonentabellen, ein Defekt bei Broadcast und Weiterleitung in einem Router oder eine kaputte NBP-Funktion im Zielknoten konnten die Frage nach dem Ort eines Agenten blockieren. Ein Datagramm an dessen bekannte Adresse konnte dennoch ankommen.

RFC 1419 empfahl deshalb seltene Suchen, gespeicherte Name-Adress-Zuordnungen und deren Erhalt über Neustarts der Managementstation. Im Normalbetrieb vermied das Wiederholungen. Im Fehlerfall gab der Cache der Station genug Unabhängigkeit, um den ausgefallenen Entdeckungsweg zu untersuchen.

Der Cache wurde damit zu Betriebszustand, nicht bloß zu wegwerfbarer Beschleunigung. Seine Nützlichkeit hing jedoch an seiner Widerrufbarkeit. War eine Zuordnung seit T1 Sekunden nicht bestätigt worden, sollte ihre Nutzerin eine Bestätigung versuchen. Der voreingestellte Mindestwert für T1 betrug 60 Sekunden und konnte konfiguriert werden.

Kritische Router konnten häufiger bestätigt werden als weniger wichtige Ziele. Eine große Station musste ihren Bestand nach dem Start nicht auf einmal abfragen; sie konnte die Suchen zeitlich strecken und nach lokaler Priorität ordnen. Die gemeinsame Spezifikation lieferte die Bestätigung. Das Netz am Rand bestimmte Frische, Last und Risiko passend zur jeweiligen Operation.

Für Traps reichte auffindbare Empfangsbereitschaft nicht

Ein Agent durfte Traps nur an namentlich konfigurierte Stationen oder eine konfigurierte Menge senden. Ohne solche Einstellung versandte er keine. Eine NBP-Wildcardsuche nach beliebigen SNMP Trap Handler-Diensten war ausdrücklich ausgeschlossen.

Ein Konfigurationswerkzeug durfte einem Menschen auffindbare Stationen zeigen. Erst dessen Auswahl wurde aber zum Betriebsverhältnis. Die Anzeige einer Fähigkeit bedeutete nicht automatisch Zustimmung, Ereignisse zu empfangen.

Auch sollte der Agent nicht alle Zuordnungen im Voraus füllen. Wenn ein Trap anstand, suchte oder bestätigte er die bestimmte Station. Für eine Antwort auf eine Anfrage galt etwas anderes: Der Ursprungssocket stand bereits im DDP-Paket, also konnte der Agent dorthin antworten. Einen Agenten verwalten, Ereignisse an eine Station senden und auf den aktuellen Absender reagieren waren drei verschiedene Beziehungen.

Die Nulladresse füllte ein Feld, ohne Wissen vorzutäuschen

Das SNMPv1-Trap-PDU enthielt agent-addr in der Form einer Internetadresse. Ein reiner AppleTalk-Agent besaß keine passende IP-Adresse. RFC 1419 verlangte deshalb Nullen im gesamten Feld. Eine erfundene IP-Identität hätte die Form erfüllt und den Sachverhalt verfälscht.

Stattdessen sollte der Trap nbpObject und nbpZone seiner SNMP Agent-Registrierung mitführen. RFC 1243 definierte beide getrennt neben nbpType und nbpState. Die äußere DDP-Quelle zeigte einen beobachteten Weg. Das Nullfeld zeigte die Grenze des geerbten IP-Modells. Die NBP-Werte lieferten eine Namensbehauptung zum Abgleich mit dem Cache.

Die Null war somit positive Grenzinformation. Der restliche Satz bewies trotzdem weder, dass das gemeldete Ereignis stattgefunden hatte, noch dass der Absender echt oder berechtigt war oder eine Reaktion erfolgte.

Ein GET konnte vergleichen; ein SET konnte bereits verändern

Eine womöglich alte Adresse konnte als Hinweis für eine gerichtete NBP-Bestätigung dienen. Alternativ konnte die Station per SNMP das NBP-Objekt und die Zone des erreichten Ziels lesen und die Werte mit Quelladresse und Soll-Eintrag vergleichen. So entstanden mehrere Beobachtungen in einem Austausch.

Vollständig schloss dieses Verfahren die Unsicherheit nicht. RFC 1419 beschrieb die Lücke anhand von SET. Fiel der alte Knoten aus und erhielt ein neuer dieselbe DDP-Adresse, erreichte die auf dem veralteten Cache beruhende SetRequest den neuen Agenten. Dessen syntaktisch korrekte Antwort kam von genau dem Ziel der Anfrage. Die Station konnte sie möglicherweise nicht von der Antwort des beabsichtigten Agenten unterscheiden.

Die falsche Zuordnung war dann nicht mehr nur ein Inventarfehler. Eine Änderung konnte am falschen Gerät wirksam werden, bevor spätere Erkenntnis den Cache berichtigte.

Das Dokument erwartete von künftiger SNMP-Sicherheit eine Authentisierung jedes Pakets am Ziel. Eine authentisierte Antwort würde die Zuordnung implizit bestätigen und das Rennen verhindern. Diese Aussage lag in der Zukunft. RFC 1419 behauptete nicht, dass stabiler Name, Adresse, Community oder passende Antwort bereits starke Identität herstellten.

Der RFC-Editor-Eintrag zu RFC 1157 markiert die historische Ausgangslage: Communities, MIB-Sichten und Zugriffsrichtlinien waren getrennt, doch Sicherheitsprobleme wurden im Abschnitt Security Considerations nicht behandelt. Eine neue Transporthülle beseitigte diese Lücke nicht.

Die Station durfte einen Teil der Entdeckung lokal nachbauen

Für eine dedizierte AppleTalk-Managementstation beschrieb RFC 1419 einen begrenzten Umweg. Scheiterte der gewöhnliche NBP-Pfad, konnte die Station selbst den Routeranteil von NBP implementieren. Mit Kenntnis der Zonen und Netze leitete sie die Suche zum zuletzt bekannten Netz des Agenten und konnte gerichtetes DDP-Multicast an die betreffenden Netznummern senden.

Die Reichweite blieb präzise. Die Kombination konnte bestimmte Einzelfehler in der NBP-Behandlung lokaler oder entfernter Router lösen. Sie versprach keine Heilung allgemeiner Partitionen, flächiger Fehlkonfiguration oder eines fehlenden Agenten. Die Zusatzlogik lag bei der spezialisierten Station, nicht als Zwang in jedem Knoten.

Darum ist die historische Aussage größer als AppleTalk. Ein widerstandsfähiges Managementsystem darf eine letzte Route behalten, wenn es zugleich Herkunft, Alter und Bestätigung dieser Route erhält. Name, Adresse, Antwortquelle, zurückgegebene Registrierung und Operationstyp müssen einzeln sichtbar bleiben. Ein einziges Merkmal „erreichbar“ würde den Unterschied zwischen kaputter Entdeckung und ausgetauschtem Gerät vernichten.