RFC 5426

RFC 5426: Transmission of Syslog Messages over UDP 🎀

Okay bestie, let's start with the title block 💅

• RFC number: 5426
• Network Working Group: this is an IETF document 🌸
• Author: A. Okmianski from Cisco Systems, Inc. ✨
• Category: Standards Track, so this is an actual standards-track protocol spec 👑
• Date: March 2009 🦋
• Obsoletes or updates: the header doesn't list anything this document obsoletes or updates 🧚

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💜. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice 🎀

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🔥.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these documents carefully, because they describe your rights and restrictions for this document 🫶.

This document might contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people controlling the copyright in some of that material might not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from whoever controls the copyright in those materials, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside the IETF Standards Process either. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🙈.

Abstract 🦋

Okay so this document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. The syslog protocol's layered architecture supports any number of transport mappings. For interoperability, though, syslog protocol implementers are required to support this transport mapping 💖.

Table of Contents 🍓

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Transport Protocol ..............................................3
   3.1. One Message Per Datagram ...................................3
   3.2. Message Size ...............................................3
   3.3. Source and Target Ports ....................................4
   3.4. Source IP Address ..........................................4
   3.5. UDP/IP Structure ...........................................4
   3.6. UDP Checksums ..............................................4
4. Reliability Considerations ......................................5
   4.1. Lost Datagrams .............................................5
   4.2. Message Corruption .........................................5
   4.3. Congestion Control .........................................5
   4.4. Sequenced Delivery .........................................5
5. Security Considerations .........................................6
   5.1. Sender Authentication and Message Forgery ..................6
   5.2. Message Observation ........................................7
   5.3. Replaying ..................................................7
   5.4. Unreliable Delivery ........................................7
   5.5. Message Prioritization and Differentiation .................7
   5.6. Denial of Service ..........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................8
8. References ......................................................8
   8.1. Normative References .......................................8
   8.2. Informative References .....................................9

---

1. Introduction ✨

Okay so, Informational RFC 3164 [8] describes the syslog protocol the way it was seen in existing implementations 🧚. It covers both the format of syslog messages and a UDP [1] transport. Later on, a Standards-Track syslog protocol was defined in RFC 5424 [2] 👑.

RFC 5424 specifies a layered architecture that supports any number of transport layer mappings for sending syslog messages. This document is the UDP transport mapping for the syslog protocol 🦋.

The transport in this document can be used to send syslog messages over both IPv4 [3] and IPv6 [4] 🌈.

Network administrators and architects need to know about the big reliability and security issues with this transport, which come from using UDP. They're all written down in this spec 🙈. But honestly, this transport is lightweight and builds on UDP's already-popular use for syslog, so it's giving practical 💅.

2. Conventions Used in This Document 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5] 🎀.

3. Transport Protocol 🌸

3.1. One Message Per Datagram 🦋

Each syslog UDP datagram MUST contain only one syslog message, and that message MAY be complete or truncated. The message MUST be formatted and truncated according to RFC 5424 [2]. Additional data MUST NOT be present in the datagram payload 💅.

3.2. Message Size ✨

This transport mapping supports sending syslog messages up to 65535 octets minus the UDP header length. That limit comes from the maximum UDP size of 65535 octets specified in RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header, because IPv4 has a 16-bit length field that also includes the header length 🧚.

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 with message sizes of up to and including 2048 octets. Being able to receive bigger messages is encouraged 🔥.

These restrictions and recommendations set a baseline for interoperability. The minimum required message size support was based on the minimum MTU that Internet hosts are required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6 [4]. Datagrams that follow these limits have the best chance of being delivered, because they don't need fragmentation 🌈.

It is RECOMMENDED that syslog senders restrict message sizes so IP datagrams don't exceed the smallest MTU of the network in use. This avoids datagram fragmentation and the issues that come with it, like incorrect MTU discovery 💖.

Fragmentation can be undesirable because it raises the risk of the message getting lost when just one datagram fragment is lost 😭. Syslog has no acknowledgement facility, so there's no effective way to handle retransmission. That makes it impossible for syslog to use packetization layer path MTU discovery [9] 💀. When the network MTU isn't known in advance, the safest assumption is to restrict messages to 480 octets for IPv4 and 1180 octets for IPv6 🫶.

3.3. Source and Target Ports 🦋

Syslog receivers MUST support accepting syslog datagrams on the well-known UDP port 514, but they MAY be configurable to listen on a different port. Syslog senders MUST support sending syslog message datagrams to UDP port 514, but they MAY be configurable to send messages to a different port. Syslog senders MAY use any source UDP port when transmitting messages 🧚.

3.4. Source IP Address 🌸

The source IP address of the UDP datagrams SHOULD NOT be treated as the identifier for the host that originated the syslog message. The sender could just be a relay 🙈. The syslog message itself contains the identifier of its originator 💜.

3.5. UDP/IP Structure 💅

Every UDP/IP datagram sent by the transport layer MUST completely adhere to the structure specified in UDP RFC 768 [1] and either IPv4 RFC 791 [3] or IPv6 RFC 2460 [4], depending on which protocol is in use 👑.

3.6. UDP Checksums ✨

Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [4] mandates the use of UDP checksums when sending UDP datagrams over IPv6 🔥.

Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums, and they SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [4] mandates checksums for UDP over IPv6 🌈.

4. Reliability Considerations 💖

UDP is an unreliable, low-overhead protocol. This section talks about the reliability issues inherent in UDP that implementers and users should know about 😭.

4.1. Lost Datagrams 🙈

This transport mapping doesn't give you any mechanism to detect and fix datagram loss. Datagrams can get lost in transit because of congestion, corruption, or any other intermittent network problem 💀. IP fragmentation makes this worse, because losing a single fragment means the entire message gets thrown away 😭.

4.2. Message Corruption 🧚

UDP/IP datagrams can get corrupted in transit because of software, hardware, or network errors. This transport mapping uses UDP checksums to help detect corruption, on top of the checksums used in IP and Layer 2 protocols. Checksums don't guarantee that corruption gets detected, though, and this transport mapping doesn't provide any message acknowledgement or retransmission mechanism 🫶.

4.3. Congestion Control 🔥

Syslog can generate unlimited amounts of data, and sending that data over UDP is generally a problem, because UDP lacks congestion control mechanisms 💅. Congestion control mechanisms that slow traffic down when there's congestion and keep a degree of fairness between flows sharing the same path are vital to the stable operation of the Internet [6] 👑. That's why the syslog TLS transport [7] is REQUIRED to implement and RECOMMENDED for general use 🌸.

The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations 🦋. In all other environments, the TLS transport [7] SHOULD be used 💜.

4.4. Sequenced Delivery 🌈

The IP transport UDP uses doesn't guarantee that datagrams get delivered in the same order they were sent 🙈. The timestamp in each syslog message can serve as a rough guide for putting messages in sequence order 🧚. But it won't help when several messages were generated in the same time slot, when the sender couldn't generate a timestamp, or when messages came from different hosts whose clocks weren't synchronized 😭. The order syslog messages arrive in over this transport SHOULD NOT be used as an authoritative guide for establishing an absolute or relative sequence of events on the syslog sender hosts 💀.

5. Security Considerations 🔐

okay bestie, the big warning first 🚨 using this spec on an unsecured network is NOT RECOMMENDED 🙅‍♀️ please don't. RFC 5424 [2] covers several general syslog security considerations. This section is all about the security stuff that's specific to syslog over UDP. Some of these issues can be mitigated by using IPsec, as defined in RFC 4301 [10] 🛡️

5.1. Sender Authentication and Message Forgery 🎭

so this transport mapping does not give you strong sender authentication 😬 the receiver can't be sure a message really came from the sender it says it came from, or whether the packet was actually sent from some other device. this can also cause mistaken identity if a badly configured machine sends syslog messages to a receiver while pretending to be a different machine 💀

this transport mapping also doesn't protect against syslog message forgery. an attacker can send syslog messages to a receiver, either pretending to be the machine the messages claim to come from or pretending to be any other machine at all 🙈

and this one is wild: an attacker can hide the real attack inside a pile of other messages 🕵️‍♀️ for example, they could start generating forged messages about a problem on some machine. that gets the sysadmins' attention, so they spend all their time chasing the fake problem. meanwhile, the attacker could be busy compromising a different machine or a different process on the same machine. main villain energy 😤

the attacker can also send false syslog messages to give untrue info about how systems are doing 📉 for example, they could stop a critical process on a machine, which would generate an exit notification. then they send a forged notification saying the process got restarted. the sysadmins might just accept that misinformation and never check whether the process had indeed not been restarted 😭

5.2. Message Observation 👀

this transport mapping doesn't keep messages confidential while they're in transit 🫣 if the syslog messages are in clear text, that's exactly how they get sent. honestly, clear-text, human-readable messages are a big help for admins 🥰 but the downside is that an attacker could also read the human-readable contents of syslog messages. then they could use what they learned to compromise a machine 💅 so it is RECOMMENDED that no sensitive information be sent via this transport mapping, or that any sending of that info be limited to properly secured networks 🔒

5.3. Replaying 🔁

message forgery and observation can team up into a replay attack 😈 an attacker could record a set of messages showing a machine doing normal stuff. later, they remove that machine from the network and replay those syslog messages with new time stamps. the admins find nothing weird in what they receive, and getting those messages makes it look like the machine is behaving normally when it really isn't 💀

5.4. Unreliable Delivery 📦

as we already talked about in Section 4, Reliability Considerations, UDP is not reliable 😩 packets carrying syslog message datagrams can get lost in transit without anyone being told. losing syslog messages can have real security consequences. admins might not even know a serious problem is brewing ⚠️ and attackers could intercept messages and throw them away to hide their unauthorized activity 🥷

5.5. Message Prioritization and Differentiation 🚦

this transport mapping does not require syslog messages to be prioritized, either on the wire or when the receiving host processes them based on severity 🙅‍♀️ unless the sender, the receiver, and/or the network implements some kind of prioritization, the receiver or network devices could get flooded with low-severity messages. then they'd be forced to throw away messages that might have been high-severity and important 😱

5.6. Denial of Service 🌪️

an attacker can overwhelm a receiver by sending it more messages than the infrastructure or the device itself can handle 🥵 implementers SHOULD try to add features that minimize this threat, like optionally restricting reception of messages to a set of known source IP addresses 🛑

6. IANA Considerations 📚

this transport uses UDP port 514 for syslog, as recorded in the IANA port-numbers registry 🗂️

7. Acknowledgements 💖

the author gratefully thanks: Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova, Devin Kowatch, Richard Graveman, and everyone else who commented on the different versions of this proposal 🫶🌈

8. References 📖

8.1. Normative References 🧾

[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[2] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.

8.2. Informative References 📝

[8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.

[9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.

[10] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

Author's Address 🦋

Anton Okmianski Cisco Systems, Inc. 595 Burrard St., Suite 2123 Vancouver, BC V7X 1J1 Canada

Phone: +1-978-936-1612 EMail: aokmians@cisco.com