Transmission of Syslog Messages over UDP
Extracted elements (24)
Fragmentation is undesirable for syslog over UDP because loss of a single fragment causes the entire message to be discarded, and syslog has no acknowledgement facility that would enable retransmission. This also makes it impossible for syslog to utilize packetization layer path MTU discovery.
The minimum required message size support values (480 octets for IPv4, 1180 octets for IPv6) were derived from the minimum MTU sizes that Internet hosts are required to support: 576 octets for IPv4 (RFC 791) and 1280 octets for IPv6 (RFC 2460). Datagrams conforming to these limits have the greatest chance of delivery without requiring IP fragmentation.
UDP was chosen as a transport for syslog because it is lightweight and builds upon the existing widespread use of UDP for syslog (as observed in RFC 3164). Administrators are warned that significant reliability and security issues stem from this choice.
RFC 5424 requires all syslog protocol implementers to support this UDP transport mapping for interoperability. The syslog TLS transport (RFC 5425) is REQUIRED to implement and RECOMMENDED for general use; UDP is a conditionally acceptable alternative only in managed networks.
Each syslog UDP datagram MUST contain only one syslog message, which MAY be complete or truncated. Additional data MUST NOT be present in the datagram payload. The message MUST be formatted and truncated according to RFC 5424.
Each UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in RFC 768 (UDP) and either RFC 791 (IPv4) or RFC 2460 (IPv6), depending on which protocol is used.
Implementers SHOULD attempt to provide features that minimize the denial-of-service threat, such as optionally restricting reception of messages to a set of known source IP addresses.
IPv4 syslog receivers MUST be able to receive datagrams with message sizes up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message sizes up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams up to and including 2048 octets.
It is RECOMMENDED that syslog senders restrict message sizes such that IP datagrams do not exceed the smallest MTU of the network in use, to avoid datagram fragmentation. When network MTU is not known, the safest assumption is 480 octets for IPv4 and 1180 octets for IPv6.
Syslog receivers MUST support accepting syslog datagrams on the well-known UDP port 514 but MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to UDP port 514 but MAY be configurable to send to a different port.
Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums. Syslog receivers MUST NOT disable UDP checksum checks; IPv4 receivers SHOULD check UDP checksums and SHOULD accept a syslog message with a zero checksum.
The order of syslog message arrival via UDP SHOULD NOT be used as an authoritative guide in establishing an absolute or relative sequence of events on the syslog sender hosts, because UDP does not guarantee delivery order.
The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the syslog message, as the sending entity could be merely a relay. The syslog message itself contains the originator identifier.
The syslog UDP transport MAY only be used as an alternative to TLS transport in managed networks where the network path has been explicitly provisioned for UDP syslog traffic via traffic engineering mechanisms such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used.
Using this specification on an unsecured network is NOT RECOMMENDED. It is RECOMMENDED that no sensitive information be transmitted via this transport mapping or that transmission of such information be restricted to properly secured networks.
This document defines the UDP transport mapping for the syslog protocol (RFC 5424), supporting transmission over both IPv4 and IPv6. It is a required transport mapping: all syslog protocol implementers are required to support it for interoperability.
This transport uses UDP port 514 for syslog, as recorded in the IANA port-numbers registry. No new registry entries are created; the existing port assignment is referenced.
An attacker can overwhelm a syslog receiver by sending more messages than the infrastructure or device can handle. Implementations should consider restricting reception to known source IP addresses as a mitigation.
Message forgery and observation can be combined into a replay attack: an attacker can record messages indicating normal machine activity, remove the machine from the network, and replay the messages with new timestamps to falsely indicate continued normal operation.
The unreliability of UDP delivery has direct security consequences: administrators may be unaware of developing problems, and an attacker can intercept and discard syslog messages to hide unauthorized activities.
This transport does not mandate message prioritization by severity. Without prioritization by sender, receiver, or network, a flood of low-severity messages can overwhelm the receiver and cause high-severity messages to be discarded.
This transport provides no confidentiality; syslog messages are transmitted in clear text. An attacker observing the network can read the human-readable contents of syslog messages and use that knowledge to compromise systems.
This transport provides no strong sender authentication. Receivers cannot verify that a syslog message was sent by the reported originator, enabling attackers to forge messages that hide attacks, misdirect administrators, or give false system status indications.
A syslog UDP datagram carries exactly one syslog message as the UDP payload, formatted per RFC 5424. Maximum payload size is 65535 octets minus the UDP header (and IP header for IPv4), derived from the 16-bit UDP length field. No framing or length prefix is added beyond the UDP header itself.