Zusammenfassung

  • Das RAW-Profil von RFC 3195 überträgt vertraute Syslog-Nachrichten über BEEP, das zuverlässige und geordnete Zustellung innerhalb eines Kanals gewährleistet; COOKED ergänzt strukturierte Einträge mit positiver oder negativer Antwort je Eintrag.
  • Diese Nachweise beantworten unterschiedliche Fragen. Ein zugestellter Frame oder <ok/> belegt weder den Ursprung des Ereignisses noch dauerhafte Speicherung, Indexierung oder eine betriebliche Reaktion.

„Zuverlässig“ kann umfassender klingen als die tatsächlich definierte Zusage. RFC 3195 erschien im November 2001 als Standards-Track-Dokument und ordnet Syslog dem verbindungsorientierten BEEP-Framework zu. Die zwei Profile machen eine technische Abwägung sichtbar. RAW setzt auf geringen Aufwand und Rückwärtskompatibilität: Das Nachrichtenformat bleibt weitgehend erhalten, BEEP liefert zuverlässig und geordnet innerhalb eines einzelnen Kanals. COOKED arbeitet mit strukturierten Operationen; jeder entry kann mit ok oder error beantwortet werden. Diese Antwort gilt für den Protokollaustausch, nicht für alle späteren Schritte einer Protokollierungskette. (RFC 3195 §§1, 3.1, 4.4.2)

Die Belege sollten getrennt werden. Ein Sender übermittelt ein Ereignis; ein BEEP-Peer empfängt die vollständige Nachricht; ein COOKED-Empfänger kann einen Eintrag akzeptieren oder ablehnen; anschließend kann ein Collector ihn parsen, schreiben, indexieren, replizieren oder einen Alarm auslösen. Das sind getrennte Zustandsänderungen. RFC 3195 spezifiziert Transport und Profilaustausch, aber keine allgemeine Speichertransaktion. Selbst <ok/> sagt nicht, ob der Collector auf dauerhaftes Medium geschrieben oder nachgelagerte Verbraucher erreicht hat. Ein error kann eine administrative Ablehnung anzeigen: Er belegt eine Richtlinienentscheidung, nicht die Nichtexistenz des Ereignisses.

RAW zeigt die Grenze konkret. Der BEEP-Abschlussmarker grenzt eine Nachricht ab; innerhalb eines Kanals gewährleistet der Transport Zuverlässigkeit und Reihenfolge. Die erste Nachricht des RAW-Listeners hat jedoch keine Syslog-Eintragssemantik; die Antworten des Initiators tragen die Einträge. Zudem ist der Körper eines RAW-Ereignisses auf 1.024 Byte begrenzt, ohne BEEP-Overhead. Das ist eine Nutzlastgrenze, keine Garantie dauerhafter Aufbewahrung. Sie unterscheidet sich von der gesamten Paketgrenze und möglichen Relay-Kürzung in RFC 3164, einem anderen Mechanismus. (RFC 3195 §3.3; RFC 3164)

RFC 3195 trennt außerdem Kommunikationsschutz von Integrität des Nachrichtenobjekts. Der Sicherheitsteil weist darauf hin, dass ein kompromittiertes Gerät falsche Nachrichten erzeugen und Relays oder Collectors Nachrichten unbemerkt ändern, einfügen oder löschen können, sofern keine weiteren Verfahren greifen. Authentifizierung, Replay-Schutz, Integrität und Vertraulichkeit sind separat bereitzustellende Dienste. Ein geschützter Kanal kann den Peer eines Hops authentifizieren; diese Identität muss weder dem Hostnamen im Ereignis entsprechen noch eine Ende-zu-Ende-Signatur des Ereignisinhalts darstellen. (RFC 3195 §§5, 10; RFC 5425 §4)

Spätere Syslog-Arbeit macht die Trennung noch deutlicher. RFC 5848 beschreibt signierte Blöcke, die Ursprungsauthentifizierung, Integrität, Replay-Schutz, Sequenzierung und Erkennung fehlender Nachrichten unterstützen können. Zugleich warnt sie, dass selbst zuverlässiger Transport keinen Verlust auf Anwendungsebene verhindert, etwa wenn der Empfänger eine TCP- oder TLS-Sitzung schließt. Das belegt weder eine breite Einführung von RFC 3195 noch, dass Signaturen jedes Aufbewahrungsproblem lösen. Es zeigt, dass Zustellung, Echtheit und Vollständigkeit unterschiedliche Belege erfordern. (RFC 5848 §§1, 8.3–8.7)

Der bleibende Wert von RFC 3195 liegt in der klaren Begrenzung. RAW kann beantworten: „Hat dieser BEEP-Kanal die Nachricht in Reihenfolge zugestellt?“ COOKED ergänzt: „Hat der Listener diesen Eintrag positiv oder negativ beantwortet?“ Ohne weitere Kontrollen beantworten beide nicht, ob das Ereignis echt war, einen Speicherausfall überstand oder eine Handlung auslöste. Für die Untersuchung sollten Sitzungsstatus, Eintragsantwort, Signaturprüfung, dauerhafte Speicherung beim Collector und nachgelagerte Verarbeitung separat dokumentiert werden.

Die RFC beschreibt Protokollverhalten; die geprüften Quellen belegen weder heutige Verbreitung noch Betriebsleistung.

Quellen: RFC 3195; aktueller RFC-Editor-Eintrag zu RFC 3195; RFC-3195-Text im IETF Datatracker; RFC 3080, BEEP-Kern; RFC 3081, BEEP über TCP; RFC 3164, BSD-Syslog-Protokoll; RFC 5424, Syslog-Protokoll; RFC 5425, TLS-Transport für Syslog; RFC 5426, UDP-Transport für Syslog; RFC 5848, signierte Syslog-Nachrichten; RFC 6587, Syslog über TCP; RFC 2782, DNS SRV; RFC 2119, Anforderungsstufen.