Reliable Delivery for syslog
Extracted elements (28)
Both profiles are mapped onto BEEP rather than raw TCP to leverage BEEP's built-in ordered reliable delivery, authentication, and privacy features. BEEP guarantees ordered reliable delivery within each channel, so both RAW and COOKED inherit this property automatically.
Two BEEP profiles are defined: RAW (high-performance, minimal footprint, backward-compatible with UDP syslog format) and COOKED (structured XML format with per-entry acknowledgment). The choice allows implementers to trade overhead for richer semantics depending on use case.
The RAW profile uses exactly the same payload format as UDP-based syslog (RFC 3164), enabling legacy syslog processing to be applied without modification. Delivery is reliable because BEEP provides in-order reliable delivery, unlike the UDP transport.
A relay MUST NOT add the 'deviceFQDN' and 'deviceIP' fields to an entry if those fields are missing and an accepted 'iam' element indicates messages are coming from another relay. Before forwarding, a relay SHOULD add these fields based on the device's 'iam' or transport address if the device did not include them.
ANS replies in the RAW profile MUST be formatted according to Section 4 of RFC 3164. If the receiver is acting as a relay, it MUST follow the relay rules in Section 4.2.2 of RFC 3164.
BEEP peer identities used for SASL authentication SHOULD correspond to the FQDN of the initiating peer; e.g., a relay on relay.example.com should use 'relay.example.com' as the SASL user ID and as the FQDN in its 'iam' element.
Devices and relays MAY discover relays and collectors via the DNS SRV algorithm, using service name 'syslog' and protocol 'tcp'. This allows central administration, fallback for failures, and static load balancing, though hardware or firewall constraints may make DNS SRV inappropriate.
Each syslog event message body in a RAW ANS reply MUST be 1024 bytes or less, excluding BEEP framing overhead. When multiple syslog messages are aggregated into a single ANS frame, each is separated by CRLF from the preceding, and there MUST NOT be a CRLF after the final message before the BEEP END trailer.
If provisioned for message authentication or replay protection or integrity, implementations SHOULD use SASL mechanism DIGEST-MD5. If provisioned to protect against unauthorized observation, implementations SHOULD use the TLS profile with cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Initiator ANS replies in the RAW profile MUST specify a facility, severity, and textual message as described in RFC 3164. The listener's opening MSG has no defined semantics and may serve as a greeting.
The 'fromIP' and 'toIP' attributes of a 'path' element MUST be the IP addresses of the respective interfaces over which the element was sent and received. The 'fromFQDN' and 'toFQDN' SHOULD be the corresponding fully qualified domain names and may be omitted if no DNS entry exists.
Upon receiving a 'path' element, the peer MUST verify that 'fromIP'/'fromFQDN' and 'toIP'/'toFQDN' match the underlying transport connection, that 'linkprops' flags match actual session attributes, and that 'pathID' is unique among all 'path' elements received on this channel.
When a relay forwards an entry, the original CDATA contents MUST be preserved unchanged; timestamps MUST NOT be rewritten in the CDATA, and the tag MUST NOT be removed from the CDATA even if also present in element attributes.
Section 8 defines reply codes used by both profiles: 200 (success), 530 (authentication required), 535 (authentication failure), 537 (action not authorized), 554 (transaction failed/policy violation), among others borrowed from SMTP-style error conventions.
The COOKED profile (URI: http://xml.resource.org/profiles/syslog/COOKED) uses application/beep+xml and defines three XML elements: 'iam' (peer identity and role), 'entry' (parsed syslog message with structured fields), and 'path' (relay chain with per-hop security properties). Each MSG is individually acknowledged with 'ok' or 'error'.
The 'entry' element carries a single syslog entry with required attributes 'facility' and 'severity', optional attributes 'timestamp', 'hostname', 'tag', 'deviceFQDN', 'deviceIP', 'pathID', and 'xml:lang'. The CDATA content is the unstructured syslog message text.
The 'iam' element identifies a peer's type (device, relay, or collector), FQDN, and IP address to the other end of a BEEP channel. The identity in effect is that of the most recently accepted 'iam'. An 'iam' may be rejected if authentication or authorization is inadequate.
The 'path' element describes the relay chain for associated 'entry' elements. Each nested 'path' element represents one hop, carrying 'fromFQDN', 'fromIP', 'toFQDN', 'toIP', 'linkprops', and a unique 'pathID'. An empty nested 'path' identifies a device; a 'path' with a nested 'path' identifies a relay.
The RAW profile (URI: http://xml.resource.org/profiles/syslog/RAW) carries syslog messages in the existing UDP format over BEEP. The listener sends the first MSG (which may be empty), and the initiator replies with ANS messages carrying syslog entries; a NUL reply indicates completion.
The syslog service defines three operational roles: device (source of syslog entries), relay (accepts entries from devices/relays and forwards to collectors/relays), and collector (sink for syslog entries). A single server may serve in all three roles simultaneously using different BEEP channels.
IANA registers two BEEP profiles for syslog: http://iana.org/beep/SYSLOG/RAW and http://iana.org/beep/SYSLOG/COOKED. The RAW profile carries no piggybacked channel-creation data; the COOKED profile may carry an 'iam' element during channel creation.
TCP port 601 is assigned as the well-known port for 'syslog-conn' (reliable syslog service). In-band negotiation over this single port determines whether the RAW or COOKED profile is in use.
BEEP provides communication security (wire protection) but not object integrity. A compromised device may generate incorrect messages undetectably, and relays or collectors can modify, insert, or delete messages without detection. Additional end-to-end techniques beyond BEEP are required to detect such compromises.
In the COOKED profile, an initiator MUST establish identity via 'iam' before 'entry' elements will be accepted; an 'entry' is rejected with error code 530 if no 'iam' has been accepted. After a successful 'iam' exchange, the initiator may send 'entry' and 'path' elements, each acknowledged with 'ok' or 'error'.
The 'entry' DTD element requires 'facility' (CDATA) and 'severity' (CDATA), and optionally carries 'timestamp', 'tag', 'deviceFQDN', 'deviceIP', 'pathID', and 'xml:lang' (defaulting to 'i-default'). PCDATA content holds the unstructured syslog message text.
The 'iam' DTD element requires attributes 'fqdn' (CDATA, REQUIRED), 'ip' (CDATA, REQUIRED), and 'type' (enumerated: device|relay|collector, REQUIRED), with optional PCDATA for human-readable location text.
The 'linkprops' attribute is a string of flag characters describing security properties of a link: 'o' (weak privacy, <80 bits), 'O' (strong privacy, ≥80 bits), 'U' (authenticated user via SASL/TLS with accepted 'iam'), 'A' (per-message authentication), 'R' (replay protection), 'I' (integrity), 'L' (reliable/loss-free delivery), 'D' (from-side is a device).
The 'path' DTD element contains an optional nested 'path' child, with 'pathID' (IDINT, REQUIRED), 'fromIP' and 'toIP' (IP, REQUIRED), 'linkprops' (ATEXT, REQUIRED), and optional 'fromFQDN' and 'toFQDN' (FQDN).