RFC 5424
The Syslog Protocol
RFC 5424: The Syslog Protocol 💌
Okay bestie, this is the big one: RFC 5424, "The Syslog Protocol." Here's the tea on its title block 🫶:
- It's from the Network Working Group 🌐
- It's Request for Comments: 5424 📜
- R. Gerhards of Adiscon GmbH wrote it 👩💻
- It's dated March 2009 🗓️
- It's a Standards Track doc, so it's a real Internet standard and not just a suggestion 👑
- It obsoletes 3164, meaning it replaces RFC 3164 💅
Status of This Memo
Okay so this doc is an Internet standards track protocol for the whole Internet community, and it's literally asking everyone to chat about it and suggest improvements 🗣️✨. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with your whole group chat 💖.
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 stood on the date this document was published. Please read those carefully, because they spell out your rights and restrictions for this document 📖. You can find them at http://trustee.ietf.org/license-info.
This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🕰️. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from whoever controls those copyrights, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside that process either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌸.
Abstract
This doc describes the syslog protocol, which is used to send around event notification messages 📣. It uses a layered architecture, so any number of transport protocols can carry syslog messages 🚚. It also has a message format that lets vendors add their own extensions in a structured way 🧩.
It was written with the original design goals of traditional syslog in mind 🎀. A new layered spec was needed because standardization work on reliable and secure syslog extensions was stuck without a Standards-Track, transport-independent RFC to build on 😭. Without this document, every other standard would have to define its own syslog packet format and transport mechanism, and over time that causes sneaky compatibility issues 💀. This doc tries to be the foundation that syslog extensions can build on 🏗️. The layered approach also means you can write the code once for each syslog feature, instead of once for each transport 🙌.
This document obsoletes RFC 3164 💅.
Table of Contents
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................4
3. Definitions .....................................................4
4. Basic Principles ................................................5
4.1. Example Deployment Scenarios ...............................6
5. Transport Layer Protocol ........................................7
5.1. Minimum Required Transport Mapping .........................7
6. Syslog Message Format ...........................................8
6.1. Message Length .............................................9
6.2. HEADER .....................................................9
6.2.1. PRI .................................................9
6.2.2. VERSION ............................................11
6.2.3. TIMESTAMP ..........................................11
6.2.4. HOSTNAME ...........................................13
6.2.5. APP-NAME ...........................................14
6.2.6. PROCID .............................................14
6.2.7. MSGID ..............................................14
6.3. STRUCTURED-DATA ...........................................15
6.3.1. SD-ELEMENT .........................................15
6.3.2. SD-ID ..............................................15
6.3.3. SD-PARAM ...........................................16
6.3.4. Change Control .....................................17
6.3.5. Examples ...........................................17
6.4. MSG .......................................................18
6.5. Examples ..................................................19
7. Structured Data IDs ............................................20
7.1. timeQuality ...............................................20
7.1.1. tzKnown ............................................21
7.1.2. isSynced ...........................................21
7.1.3. syncAccuracy .......................................21
7.1.4. Examples ...........................................21
7.2. origin ....................................................22
7.2.1. ip .................................................22
7.2.2. enterpriseId .......................................22
7.2.3. software ...........................................23
7.2.4. swVersion ..........................................23
7.2.5. Example ............................................23
7.3. meta ......................................................24
7.3.1. sequenceId .........................................24
7.3.2. sysUpTime ..........................................24
7.3.3. language ...........................................24
8. Security Considerations ........................................24
8.1. UNICODE ...................................................24
8.2. Control Characters ........................................25
8.3. Message Truncation ........................................26
8.4. Replay ....................................................26
8.5. Reliable Delivery .........................................26
8.6. Congestion Control ........................................27
8.7. Message Integrity .........................................28
8.8. Message Observation .......................................28
8.9. Inappropriate Configuration ...............................28
8.10. Forwarding Loop ..........................................29
8.11. Load Considerations ......................................29
8.12. Denial of Service ........................................29
9. IANA Considerations ............................................30
9.1. VERSION ...................................................30
9.2. SD-IDs ....................................................30
10. Working Group .................................................31
11. Acknowledgments ...............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
Appendix A. Implementer Guidelines ...............................34
A.1. Relationship with BSD Syslog ..............................34
A.2. Message Length ............................................35
A.3. Severity Values ..........................................36
A.4. TIME-SECFRAC Precision ....................................36
A.5. Case Convention for Names ................................36
A.6. Syslog Applications Without Knowledge of Time ............37
A.7. Notes on the timeQuality SD-ID ............................37
A.8. UTF-8 Encoding and the BOM ................................371. Introduction ✨
This doc describes a layered architecture for syslog 🥞. The whole goal is to separate message content from message transport, while keeping each layer easy to extend 🔧.
It also describes the standard format for syslog messages and lays out the idea of transport mappings 🗺️. On top of that, it describes structured data elements. These carry easy-to-parse, structured info, and they leave room for vendor extensions 💜.
This document does not describe any storage format for syslog messages. Storage is outside the scope of the syslog protocol, and it isn't needed for systems to interoperate 🗄️.
This doc was written with the original design goals of traditional syslog in mind. A new layered spec was needed because standardization efforts for reliable and secure syslog extensions were missing a Standards-Track, transport-independent RFC 😤. Without this document, every other standard would need to define its own syslog packet format and transport mechanism, and over time that introduces subtle compatibility issues 🙈. This doc tries to be a foundation that syslog extensions can build on 🏗️. The layered approach also gives you a solid base for writing code once per syslog feature, instead of once per transport 🫶.
This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field 🌷.
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 [RFC2119]. These are the official BCP 14 key words, so read them as proper requirement levels, not casual vibes 📏.
3. Definitions 🧩
Syslog is built out of three layers 🍰:
- "syslog content" is the management information contained in a syslog message.
- The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
- The "syslog transport" layer puts messages on the wire and takes them off the wire.
Certain types of functions get performed at each conceptual layer 🎭:
- An "originator" generates syslog content to be carried in a message.
- A "collector" gathers syslog content for further analysis.
- A "relay" forwards messages. It accepts messages from originators or other relays, and sends them on to collectors or other relays.
- A "transport sender" passes syslog messages to a specific transport protocol.
- A "transport receiver" takes syslog messages from a specific transport protocol.
Diagram 1 shows the different entities, separated by layer 👀.
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------Diagram 1. Syslog Layers
4. Basic Principles ✨
okay so bestie, here are the big vibes of how syslog talks to itself 🫶 💖
- The syslog protocol does not provide acknowledgment of message delivery. Some transports might give you status info, but conceptually syslog is a pure simplex communications protocol. It's one-way, no read receipts, no "seen" 💀
- Originators and relays may be configured to send the same message to multiple collectors and relays. Copies, copies everywhere 🦋
- Originator, relay, and collector functionality may reside on the same system. One device can wear multiple hats, it's giving multitasker 👑
4.1. Example Deployment Scenarios
okay here are some sample setups 🧚 Other arrangements of these are also acceptable, so don't panic if your network looks different. As noted in the diagram, relays may send all or some of the messages they receive, and they can also send messages they generate internally. The boxes are syslog-enabled applications 🎀
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+Diagram 2. Some Possible Syslog Deployment Scenarios
5. Transport Layer Protocol 🚀
this doc doesn't define any transport layer protocol, bestie. Instead it describes the format of a syslog message in a way that doesn't care which transport you use 💅 Syslog transports are defined in other documents. One of them is defined in [RFC5426] and matches the traditional UDP transport. That one's needed for interoperability, because UDP has historically been used to send syslog messages, so it's a whole legacy moment 🌸
Any syslog transport protocol MUST NOT deliberately alter the syslog message 🙅♀️ If the transport protocol needs to do temporary transformations at the transport sender, those transformations MUST be reversed by the transport protocol at the transport receiver. That way the relay or collector sees an exact copy of what the originator or relay generated. Otherwise, end-to-end cryptographic verifiers (like signatures) will break, and that's a disaster 😭 Of course, message alteration could still happen due to transmission errors or other problems. Guarding against that is not within the scope of this document, so it's not our job here 🫠
5.1. Minimum Required Transport Mapping
All implementations of this specification MUST support a TLS-based transport as described in [RFC5425]. Non-negotiable, bestie 🔐
All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426].
It is RECOMMENDED that deployments of this specification use the TLS-based transport. So yeah, lowkey the glow-up choice 🌈✨
6. Syslog Message Format 🎀
the syslog message has the following ABNF [RFC5234] definition. ABNF is the grammar language, and this is the blueprint for how a message is built 🧩
SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
SP APP-NAME SP PROCID SP MSGID
PRI = "<" PRIVAL ">"
PRIVAL = 1*3DIGIT ; range 0 .. 191
VERSION = NONZERO-DIGIT 0*2DIGIT
HOSTNAME = NILVALUE / 1*255PRINTUSASCII
APP-NAME = NILVALUE / 1*48PRINTUSASCII
PROCID = NILVALUE / 1*128PRINTUSASCII
MSGID = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR = 4DIGIT
DATE-MONTH = 2DIGIT ; 01-12
DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
FULL-TIME = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
[TIME-SECFRAC]
TIME-HOUR = 2DIGIT ; 00-23
TIME-MINUTE = 2DIGIT ; 00-59
TIME-SECOND = 2DIGIT ; 00-59
TIME-SECFRAC = "." 1*6DIGIT
TIME-OFFSET = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
MSG = MSG-ANY / MSG-UTF8
MSG-ANY = *OCTET ; not starting with BOM
MSG-UTF8 = BOM UTF-8-STRING
BOM = %xEF.BB.BF
UTF-8-STRING = *OCTET ; UTF-8 string as specified
; in RFC 3629
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
NILVALUE = "-"6.1. Message Length 📏
message size limits are set by whichever syslog transport mapping you're using. There's no upper limit per se, but each transport mapping defines the minimum maximum required message length support. And that minimum maximum MUST be at least 480 octets in length. Bare minimum, no excuses 💅
Any transport receiver MUST be able to accept messages of up to and including 480 octets in length. All transport receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Transport receivers MAY receive messages larger than 2048 octets in length. If a transport receiver gets a message bigger than it supports, the transport receiver SHOULD truncate the payload. Alternatively, it MAY discard the message. Choose your fighter 🥊
If a transport receiver truncates messages, the truncation MUST occur at the end of the message. After truncation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA. In that case the transport receiver MAY discard the message or MAY try to process as much as possible. Messy, but valid choices 🙈
6.2. HEADER 🧾
The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field, as described in [RFC5234]. These are the ASCII codes defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. Old-school energy, iconic 📼
The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1. Respect the elders 🫶
6.2.1. PRI 🎯
The PRI part MUST have three, four, or five characters, and it's bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character, %d60), followed by a number, which is then followed by a ">" ('greater-than' character, %d62). The number inside those angle brackets is the Priority value (PRIVAL), and it represents both the Facility and the Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9") ✨
Facility and Severity values are not normative but often used, so they're here purely for informational vibes 🍓 The Facility table is below. Facility values MUST be in the range of 0 to 23 inclusive.
Numerical Facility
Code
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon (note 2)
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
Table 1. Syslog Message FacilitiesEach message Priority also has a decimal Severity level indicator 🚨 The table is below, with the numerical values. Severity values MUST be in the range of 0 to 7 inclusive.
Numerical Severity
Code
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
Table 2. Syslog Message SeveritiesThe Priority value is calculated by multiplying the Facility number by 8, then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. A "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165 🧮 In the PRI of a syslog message, those values go between the angle brackets as <0> and <165> respectively. The only time a value of "0" follows the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used. No padding, bestie, we don't do that here 🙅♀️💜
6.2.2. VERSION 🔖
VERSION tells you which version of the syslog protocol spec the message follows 💅. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of 1. The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in [RFC5226].
6.2.3. TIMESTAMP ⏰
TIMESTAMP is a formalized timestamp derived from [RFC3339] 🕰️
[RFC3339] allows a bunch of different syntaxes, but this document adds more rules on top, so it's way more locked in. The TIMESTAMP value MUST follow these restrictions:
- The "T" and "Z" characters in this syntax MUST be upper case.
- Usage of the "T" character is REQUIRED.
- Leap seconds MUST NOT be used.
The originator SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The "timeQuality" SD-ID described in Section 7.1 lets the originator say how accurate and trustworthy the timestamp is 🧐
A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time 🥲
6.2.3.1. Examples 🌈
Example 1
1985-04-12T23:20:50.52ZThis represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC.
Example 2
1985-04-12T19:20:50.52-04:00Same time as Example 1, just expressed in US Eastern Standard Time (observing daylight savings time) 🗽
Example 3
2003-10-11T22:14:15.003ZThis represents 11 October 2003 at 10:14:15pm, 3 milliseconds into the next second. The timestamp is in UTC and gives millisecond resolution. The creator may have actually had better resolution, but three digits for the fractional part of a second doesn't tell us that 🤷♀️
Example 4
2003-08-24T05:14:15.000003-07:00This represents 24 August 2003 at 05:14:15am, 3 microseconds into the next second. The microsecond resolution shows up in the extra digits in TIME-SECFRAC. The timestamp says its local time is -7 hours from UTC, so this one might've been made in the US Pacific time zone during daylight savings time 🌴
Example 5 - An Invalid TIMESTAMP 🙅♀️
2003-08-24T05:14:15.000000003-07:00This is basically Example 4, but TIME-SECFRAC is in nanoseconds now. That makes TIME-SECFRAC longer than the allowed 6 digits, which invalidates it 💀
6.2.4. HOSTNAME 🖥️
HOSTNAME identifies the machine that originally sent the syslog message 📍
The HOSTNAME field SHOULD contain the hostname and the domain name of the originator in the format specified in STD 13 [RFC1034]. This format is called a Fully Qualified Domain Name (FQDN) in this document 🌐
Real talk, not every syslog application can give you an FQDN. So other values MAY also be present in HOSTNAME. This document has provisions for using other values in those situations. A syslog application SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows:
- FQDN
- Static IP address
- hostname
- Dynamic IP address
- the NILVALUE
If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [RFC1035]. If an IPv6 address is used, a valid textual representation as described in [RFC4291], Section 2.2, MUST be used 🔢
Syslog applications SHOULD consistently use the same value in the HOSTNAME field for as long as possible. Consistency is everything, periodt 💜
The NILVALUE SHOULD only be used when the syslog application has no way to obtain its real hostname. This situation is considered highly unlikely 🙃
6.2.5. APP-NAME 🧩
The APP-NAME field SHOULD identify the device or application that originated the message. It's a string without further semantics, and it's meant for filtering messages on a relay or collector 🔍
The NILVALUE MAY be used when the syslog application has no idea of its APP-NAME or cannot provide that information. A device might be unable to provide it because of a local policy decision, or because the information is not available, or not applicable, on the device 🤫
This field MAY be operator-assigned 🛠️
6.2.6. PROCID 🆔
PROCID is a value included in the message. It has no interoperable meaning, except that a change in the value indicates there has been a discontinuity in syslog reporting ✨ The field doesn't have any specific syntax or semantics. The value is implementation-dependent and/or operator-assigned. The NILVALUE MAY be used when no value is provided.
PROCID is often used to provide the process name or process ID associated with a syslog system. The NILVALUE might be used when a process ID isn't available. On an embedded system with no operating system process ID, PROCID might be a reboot ID 🔌
PROCID can help log analyzers spot discontinuities in syslog reporting, by noticing a change in the syslog process ID. BUT (and this is important) PROCID is not a reliable way to identify a restarted process, since the restarted syslog process might get the same process ID as the previous one 😬
PROCID can also be used to tell which messages belong to a group. For example, an SMTP mail transfer agent might put its SMTP transaction ID into PROCID, so the collector or relay can group messages by that SMTP transaction 📬
6.2.7. MSGID 🏷️
The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID TCPIN for incoming TCP traffic and TCPOUT for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It's meant for filtering messages on a relay or collector 🧃
The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value.
This field MAY be operator-assigned.
6.3. STRUCTURED-DATA 🗂️
STRUCTURED-DATA gives you a way to express information in a well defined, easily parseable and interpretable data format. There are lots of usage scenarios. For example, it can express meta-information about the syslog message, or application-specific info like traffic counters or IP addresses 📊
STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which this document calls "SD-ELEMENT" 🧱
If there are zero structured data elements, the STRUCTURED-DATA field MUST contain the NILVALUE.
The character set used in STRUCTURED-DATA MUST be seven-bit ASCII in an eight-bit field, as described in [RFC5234]. These are the ASCII codes defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. The one exception is the PARAM-VALUE field (see Section 6.3.3), which MUST use UTF-8 encoding 🌏
A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration 🚚
6.3.1. SD-ELEMENT 🧬
An SD-ELEMENT is made of a name and parameter name-value pairs. The name is called the SD-ID. The name-value pairs are called "SD-PARAM" 🎀
6.3.2. SD-ID 🪪
SD-IDs are case-sensitive, and they uniquely identify the type and purpose of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a message 🚫
There are two formats for SD-ID names:
- Names that do not contain an at-sign (
@, ABNF %d64) are reserved to be assigned by IETF Review as described in BCP26 [RFC5226]. Currently, these are the names defined in Section 7. Names of this format are only valid if they are first registered with the IANA. Registered names MUST NOT contain an at-sign (@, ABNF %d64), an equal-sign (=, ABNF %d61), a closing brace (], ABNF %d93), a quote-character (", ABNF %d34), whitespace, or control characters (ASCII code 127 and codes 32 or less). - Anyone can define additional SD-IDs using names in the format
name@<private enterprise number>, e.g.,ourSDID@32473. The format of the part before the at-sign is not specified. However, these names MUST be printable US-ASCII strings, and MUST NOT contain an at-sign (@, ABNF %d64), an equal-sign (=, ABNF %d61), a closing brace (], ABNF %d93), a quote-character (", ABNF %d34), whitespace, or control characters. The part after the at-sign MUST be a private enterprise number as specified in Section 7.2.2. Heads up: throughout this document the value 32473 is used for all private enterprise numbers, because IANA reserved it as an example number for documentation. Implementors will need to use their own private enterprise number for the enterpriseId parameter, and when creating locally extensible SD-ID names 🏢
6.3.3. SD-PARAM 🔑
Each SD-PARAM is made of a name, called PARAM-NAME, and a value, called PARAM-VALUE.
PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, except the ones in SD-IDs whose names contain an at-sign. The PARAM-NAME scope is within a specific SD-ID, so equally named PARAM-NAME values in two different SD-IDs are NOT the same thing (they're totally different, bestie) 👯
To support international characters, the PARAM-VALUE field MUST be encoded using UTF-8. A syslog application MAY issue any valid UTF-8 sequence. A syslog application MUST accept any valid UTF-8 sequence in the "shortest form". It MUST NOT fail if control characters are present in PARAM-VALUE. The syslog application MAY modify messages containing control characters (for example, by changing an octet with value 0 (USASCII NUL) to the four characters #000). For the reasons outlined in UNICODE TR36 [UNICODE-TR36], section 3.1, an originator MUST encode messages in the "shortest form", and a collector or relay MUST NOT interpret messages in the "non-shortest form" 🌍
Inside PARAM-VALUE, the characters " (ABNF %d34), \ (ABNF %d92), and ] (ABNF %d93) MUST be escaped. This is necessary to avoid parsing errors. Escaping ] would not strictly be necessary, but it is REQUIRED by this specification to avoid syslog application implementation errors. Each of these three characters MUST be escaped as \", \\, and \] respectively. The backslash is used for control character escaping, for consistency with its use for escaping in other parts of the syslog message as well as in traditional syslog 🪄
A backslash (\) followed by none of the three described characters is considered an invalid escape sequence. In this case, the backslash MUST be treated as a regular backslash and the following character as a regular character. Thus, the invalid sequence MUST not be altered 🙈
An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT 🔁
6.3.4. Change Control 🔒
Once SD-IDs and PARAM-NAMEs are defined, the syntax and semantics of these objects MUST NOT be altered. If you want to change an existing object, a new SD-ID or PARAM-NAME MUST be created, and the old one stays unchanged. OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID 💖
6.3.5. Examples 💅
okay so every example in this bit only shows the structured data part of the message 🎀 ✨ they're meant to be read as one line, even though I've wrapped them across a few lines so they're easier to read 🥹 each one gets a little description after it.
Example 1 - Valid 💖
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"]this is a structured data element with a non-IANA controlled SD-ID of type "exampleSDID@32473", and it has three parameters 🦋
Example 2 - Valid 🌸
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]this is the same as Example 1, just with a second structured data element tacked on 💜 notice that the second element sits right up against the first one, with no SP between them 👀
Example 3 - Invalid 🙈
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]this is nearly Example 2, but there's a sneaky little mistake 💀 there's an SP character between the two structured data elements ("]SP["). this is invalid. it'll make the STRUCTURED-DATA field end after the first element, so the second element gets treated as part of the MSG field. not it 😭
Example 4 - Invalid 🥀
[ exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"][examplePriority@32473 class="high"]this one is also nearly Example 2, with another subtle slip 🙃 the SP character shows up right after the opening bracket. a structured data element SD-ID MUST immediately follow the beginning bracket, so that SP wrecks the whole STRUCTURED-DATA. a syslog application MAY discard this message. bestie, don't be this one 💅
Example 5 - Valid 🌈
[sigSig ver="1" rsID="1234" ... signature="..."]Example 5 is valid ✨ it shows a hypothetical IANA-assigned SD-ID. the ellipses stand in for content that's been left out for brevity 🧚
6.4. MSG 🍓
the MSG part is the free-form message that tells you what happened 💖
the character set used in MSG SHOULD be UNICODE, encoded with UTF-8 as specified in [RFC3629]. if the syslog application can't encode the MSG in Unicode, it MAY use any other encoding 🌸
the syslog application SHOULD avoid octet values below 32 (that's the traditional US-ASCII control character range, except DEL) 🙈 those values are legal, but a syslog application MAY modify these characters upon reception. for example, it might turn them into an escape sequence, like changing value 0 into "\0". a syslog application SHOULD NOT modify any other octet values 🫶
if a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM). for UTF-8 that's the ABNF %xEF.BB.BF. the syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence 🔥
if a syslog application is processing an MSG that starts with a BOM and the MSG contains UTF-8 that is not in shortest form, the MSG MUST NOT be interpreted as UTF-8, for the reasons laid out in [UNICODE-TR36], Section 3.1. there's guidance about this in Appendix A.8 📚
also, according to UNICODE TR36 [UNICODE-TR36], a syslog application MUST NOT interpret messages in the "non-shortest form". it MUST NOT interpret invalid UTF-8 sequences either 💅
6.5. Examples 🦋
the following are examples of valid syslog messages ✨ each one has a description right under it. they're based on similar examples from [RFC3164], so you might recognise them 👀 the BOM is basically unprintable Unicode, so the examples write it out as "BOM" 🎀
Example 1 - with no STRUCTURED-DATA 💜
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
- BOM'su root' failed for lonvick on /dev/pts/8in this one the VERSION is 1 and the Facility is 4 🌸 the Severity is 2. the message was created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the next second ⭐ it came from a host that calls itself "mymachine.example.com". the APP-NAME is "su" and the PROCID is unknown. the MSGID is "ID47". the MSG is "'su root' failed for lonvick...", encoded in UTF-8, and the BOM is what tells you that encoding 🫶 there's no STRUCTURED-DATA here, which is why the STRUCTURED-DATA field just says "-".
Example 2 - with no STRUCTURED-DATA 🧚
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1
myproc 8710 - - %% It's time to make the do-nuts.the VERSION is 1 again 💖 the Facility is 20 and the Severity is 5. this was created on 24 August 2003 at 5:14:15am, with a -7 hour offset from UTC, 3 microseconds into the next second 🍓 the HOSTNAME is "192.0.2.1", which means the syslog application didn't know its FQDN, so it used one of its IPv4 addresses instead 🙃 the APP-NAME is "myproc" and the PROCID is "8710" (this could be the UNIX PID, for example). no STRUCTURED-DATA again, shown by the "-" in that field. and there's no specific MSGID, so that's the "-" in the MSGID field.
the message is "%% It's time to make the do-nuts." since the Unicode BOM is missing, the syslog application has no idea what encoding the MSG part is in 🤷♀️
Example 3 - with STRUCTURED-DATA 🌈
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...this one is modelled on Example 1, but this time it has STRUCTURED-DATA: a single element with the value [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] 💅 the MSG itself is "An application event log entry...". the BOM at the start of MSG tells you it's UTF-8 ✨
Example 4 - STRUCTURED-DATA Only 👑
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"][examplePriority@32473
class="high"]this one has only STRUCTURED-DATA and no MSG part at all 🫶 and yes, it's a valid message, so no drama 🦋
7. Structured Data IDs ✨
this section defines the initial IANA-registered SD-IDs 💖 if you need a refresher on what structured data elements are, see Section 6.3. every SD-ID defined here is OPTIONAL 🎀
a few of the parameters below have a maximum length. for each of those, the syslog application MUST be prepared to receive that many characters in any valid UTF-8 code point. since each character can be up to 6 octets, it is RECOMMENDED that each syslog application be prepared to receive up to 6 octets per character 🧚 (so yes, be generous, bestie)
7.1. timeQuality ⏰
the SD-ID "timeQuality" MAY be used by the originator to describe its notion of system time 🌸 this SD-ID SHOULD be written if the originator isn't properly synchronized with a reliable external time source, or if it doesn't know whether its time zone information is correct 🙈 the main point of this element is to tell you how much trust you can put in the TIMESTAMP described in Section 6.2.3. all parameters are OPTIONAL 💜
7.1.1. tzKnown 🌍
the "tzKnown" parameter says whether the originator knows its time zone 💖 if it does, the value "1" MUST be used. if the time zone information is in doubt, the value "0" MUST be used. and if the originator knows its time zone but decides to emit time in UTC anyway, the value "1" MUST be used, because the time zone is known ✨
7.1.2. isSynced 🔁
the "isSynced" parameter says whether the originator is synchronized to a reliable external time source, like via NTP 🕰️ if the originator is time synchronized, the value "1" MUST be used. if not, the value "0" MUST be used 🫶
7.1.3. syncAccuracy 🎯
the "syncAccuracy" parameter says how accurate the originator thinks its time sync is 🦋 it's an integer for the maximum number of microseconds its clock may be off between sync intervals.
if "0" is used for "isSynced", this parameter MUST NOT be specified 🙅♀️ if "1" is used for "isSynced" but "syncAccuracy" is absent, a collector or relay can assume the time info is accurate enough to be considered correct 👀 the "syncAccuracy" parameter MUST be written only if the originator actually knows how reliable its external time source is. most of the time, it'll learn that through operator configuration 🧠
7.1.4. Examples 💅
the following is an example of an originator that doesn't know its time zone or whether it's being synchronized:
[timeQuality tzKnown="0" isSynced="0"]so the originator is basically saying its time info is unreliable 😭 that can be a hint for the collector or relay to use its own local time instead of the TIMESTAMP in the message when it correlates messages from different originators 🌈
the following is an example of an originator that knows its time zone and knows it's properly synced to a reliable external source:
[timeQuality tzKnown="1" isSynced="1"]and this one is an originator that knows both its time zone and that it's externally synchronized, plus how accurate that sync is 🤩
[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]the difference from the previous example is that this originator expects its clock to stay within 60 seconds of the official time 🕘 so if it reports 9:00:00, it's no earlier than 8:59:00 and no later than 9:01:00 ⭐
7.2. origin 🌷
the SD-ID "origin" MAY be used to show where a syslog message came from 🧚 these parameters can be used, and all of them are OPTIONAL 💖
specifying any of these is mainly a help for log analyzers and similar apps 📊
7.2.1. ip 🌐
the "ip" parameter is an IP address that the originator knows it had at the time it sent the message. it MUST contain the textual representation of an IP address as outlined in Section 6.2.4 🎀
this parameter can add identifying info on top of what's in the HOSTNAME field. it can be especially handy when the IP address is in the message but the HOSTNAME field still has the FQDN 🫶 it's also useful for describing all the IP addresses of a multihomed host 🌈
if an originator has multiple IP addresses, it MAY either list just one of them in the "ip" parameter, or it MAY include multiple "ip" parameters in a single "origin" structured data element 💜
7.2.2. enterpriseId ✨
The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code' 🎀, maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Okay so the number that follows MUST be unique and MUST be registered with IANA as per RFC 2578 [RFC2578] 💅. An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree assigned by IANA to that enterprise 🦋. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree 🔥. In general, only the IANA-assigned private enterprise number is needed (a single number) 🌸. An enterprise might decide to use sub-identifiers below its private enterprise number 👑. If sub-identifiers are used, they MUST be separated by periods and be represented as decimal numbers 🧚. An example for that would be "32473.1.2" ✨. Please note that the ID "32473.1.2" is just an example and MUST NOT be used 🙈. The complete up-to-date list of Private Enterprise Numbers (PEN) is maintained by IANA 🌈.
By specifying a private enterprise number, the vendor allows more specific processing of the message 🫶.
7.2.3. software ✨
The "software" parameter uniquely identifies the software that generated the message 💜. If it is used, "enterpriseId" SHOULD also be specified, so that a specific vendor's software can be identified 🍓. The "software" parameter is not the same as the APP-NAME header field 🙈. It MUST always contain the name of the generating software, whereas APP-NAME can contain anything else, including an operator-configured value 💅.
The "software" parameter is a string. It MUST NOT be longer than 48 characters 🎀.
7.2.4. swVersion ✨
The "swVersion" parameter uniquely identifies the version of the software that generated the message 🦋. If it is used, the "software" and "enterpriseId" parameters SHOULD be provided, too 🌸.
The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters 💖.
7.2.5. Example 🌈
The following is an example with multiple IP addresses:
[origin ip="192.0.2.1" ip="192.0.2.129"]In this example, the originator indicates that it has two IP addresses, one being 192.0.2.1 and the other one being 192.0.2.129 🫶.
7.3. meta 🧚
The SD-ID "meta" MAY be used to provide meta-information about the message 💜. The following parameters can be used. All parameters are OPTIONAL. If the "meta" SD-ID is used, at least one parameter SHOULD be specified 🍓.
7.3.1. sequenceId ✨
The "sequenceId" parameter tracks the sequence in which the originator submits messages to the syslog transport for sending 🦋. It is an integer that MUST be set to 1 when the syslog function is started and MUST be increased with every message up to a maximum value of 2147483647 👑. If that value is reached, the next message MUST be sent with a sequenceId of 1 💅.
7.3.2. sysUpTime ✨
The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message 🌸. Its syntax and semantics are as defined in [RFC3418] 🎀.
As syslog does not support the SNMP "INTEGER" syntax directly, the value MUST be represented as a decimal integer (no decimal point) using only the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", and "9" 🔥.
Note that the semantics in RFC 3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." 🙈 This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system 💜.
7.3.3. language ✨
The "language" parameter MAY be specified by the originator to convey information about the natural language used inside MSG 🌈. If it is specified, it MUST contain a language identifier as defined in BCP 47 [RFC4646] 🫶.
- Security Considerations 🔥
8.1. UNICODE 💀
This document uses UTF-8 encoding for the PARAM-VALUE and MSG fields 🦋. There are a number of security issues with UNICODE. Any implementer and operator is advised to review UNICODE TR36 [UNICODE-TR36] (UTR36) to learn about these issues 👑. This document guards against the technical issues outlined in UTR36 by REQUIRING "shortest form" encoding for syslog applications 💅. However, the visual spoofing due to character confusion still persists 😭. This document tries to minimize the effects of visual spoofing by allowing UNICODE only where local script is expected and needed 🌸. In all other fields, US-ASCII is REQUIRED 🎀. Also, the PARAM-VALUE and MSG fields should not be the primary source for identifying information, further reducing the risks associated with visual spoofing 💖.
8.2. Control Characters 💀
This document does not impose any mandatory restrictions on the MSG or PARAM-VALUE content 🌈. As such, they MAY contain control characters, including the NUL character 🧚.
In some programming languages (most notably C and C++), the NUL character (ABNF %d00) traditionally has a special significance as string terminator 🔥. Most implementations of these languages assume that a string will not extend beyond the first NUL character 👑. This is primarily a restriction of the supporting run-time libraries 🙈. This restriction is often carried over to programs and script languages written in those languages 🫶. As such, NUL characters must be considered with great care and be properly handled 😭. An attacker may deliberately include NUL characters to hide information after them 💀. Incorrect handling of the NUL character may also invalidate cryptographic checksums that are transmitted inside the message 🦋.
Many popular text editors are also written in languages with this restriction 💅. Encoding NUL characters when writing to text files is advisable 🍓. If they are stored without encoding, the file can become unreadable 💜.
Other control characters may also be problematic 🌸. For example, an attacker may deliberately include backspace characters to render parts of the log message unreadable 🎀. Similar issues exist for almost all control characters 🔥.
Finally, invalid UTF-8 sequences may be used by an attacker to inject ASCII control characters 👑.
This specification permits a syslog application to reformat control characters received 💖. Among others, the security risks associated with control characters were an important driving force behind this restriction 🌈. Originators are advised that if any encoding other than ASCII and UTF8 are used, the receiver may corrupt the message in an attempt to filter ASCII control characters 🫶.
8.3. Message Truncation 💀
Message truncation can be misused by an attacker to hide vital log information 😭. Messages over the minimum supported size may be discarded or truncated by the transport receiver 🦋. As such, vital log information may be lost 💅.
In order to prevent information loss, messages should not be longer than the minimum maximum size required by Section 6.1 🌸. For best performance and reliability, messages should be as small as possible 🎀. Important information should be placed as early in the message as possible because information at the beginning of the message is less likely to be discarded by a size-limited transport receiver 🧚.
An originator should limit the size of any user-supplied data within a syslog message 💜. If it does not, an attacker may provide large data in hopes of exploiting a potential weakness 🔥.
8.4. Replay 💀
There is no mechanism in the syslog protocol to detect message replay 🙈. An attacker may record a set of messages that indicate normal activity of a machine 🦋. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the relay or collector 👑. Even with the TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them 💅. The administrators may find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine 😭.
Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack 🌈.
8.5. Reliable Delivery 💀
Because there is no mechanism described within this document to ensure delivery, and the underlying transport may be unreliable (e.g., UDP), some messages may be lost 😭. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded 🦋. The consequences of dropping one or more syslog messages cannot be determined 🙈. If the messages are simple status updates, then their non-receipt may not be noticed or may cause an annoyance for the system operators 💅. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem 💀. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities 🔥.
It may also be desirable to include rate-limiting features in syslog originators and relays 🌸. This can reduce potential congestion problems when message bursts happen 🎀.
Reliable delivery may not always be desirable 🧚. Reliable delivery means that the syslog originator or relay must block when the relay or collector is not able to accept any more messages 💜. In some operating systems, namely Unix/Linux, the syslog originator or relay runs inside a high-priority system process (syslogd) 👑. If that process blocks, the system at large comes to a stand-still 😭. The same occurs if there is a deadlock situation between syslogd and e.g., the DNS server 💀.
To prevent these problems, reliable delivery can be implemented in a way that intentionally discards messages when the syslog application would otherwise block 🌈. The advantage of reliable delivery in this case is that the syslog originator or relay knowingly discards the message and is able to notify the relay or collector about that fact 🫶. So the relay or collector receives the information that something is lost 🦋. With unreliable delivery, the message would simply be lost without any indication that loss occurred 💖.
8.6. Congestion Control 🚦
okay so bestie, syslog can spit out an unlimited amount of data 😭, and sending that over UDP is lowkey a problem because UDP has no congestion control 💀. Congestion control is the stuff that slows traffic down when the network is struggling and keeps flows fair with each other on the same path, and it's vital for the Internet to stay stable 🫶 [RFC2914]. That's why the syslog TLS transport is REQUIRED to implement 🔥 and RECOMMENDED for general use 💖.
The only places the syslog UDP transport MAY be used as an alternative to TLS are managed networks ✨, where the path has been explicitly set up for UDP syslog traffic with traffic engineering stuff like rate limiting or capacity reservations 🎀. Everywhere else, the TLS transport SHOULD be used 💅.
Any implementation can end up in a spot where an originator or relay has to block sending messages 🙈. A super common case is when an internal queue is full, which can happen because of rate-limiting or because the syslog app is slow 🐢. Either way, it is highly RECOMMENDED that no messages get dropped, and that they get temporarily stored until they can be sent 🌸. But if they really must be dropped, it is RECOMMENDED that the originator or relay drops the lower severity ones first and keeps the higher severity ones 👑.
Messages with a lower numerical SEVERITY value have a higher practical severity than ones with a higher number, so that's the situation where the messages that are going to be dropped SHOULD simply be discarded 🗑️. The syslog app may notify a collector or relay that it dropped messages 💌.
8.7. Message Integrity 🔐
Besides getting discarded, syslog messages can get damaged in transit 😬, or an attacker might maliciously modify them 👿. In those cases, the original contents of the message will not be delivered to the collector or relay 🚫. Also, if an attacker is sitting between the transport sender and transport receiver, they may be able to intercept and modify messages while they're in transit to hide unauthorized activities 🕵️♀️.
8.8. Message Observation 👀
So there are no strict guidelines for the MSG format 🤷♀️, but most syslog messages are made to be human-readable, with the assumption that capable admins should be able to read them and understand what they mean 📖. The syslog protocol does not have mechanisms to provide confidentiality for messages in transit 🙅♀️. In most cases, clear-text messages are actually a benefit to the ops staff if they're sniffing packets off the wire 🦋. They can read the messages and connect them with other events from other packets crossing the wire, which helps them track down and fix problems 🔧. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages 😱. They can use what they learn from those messages to compromise a machine or do other damage 💀.
Operators are advised to use a secure transport mapping to avoid this problem 🔒.
8.9. Inappropriate Configuration 🙃
Because there is no control information distributed about any messages or configurations, it is totally the responsibility of the network administrator to make sure messages are actually going to the intended recipients 📬. Cases have been noted where syslog apps were accidentally configured to send messages to the wrong relays or collectors 😵. In many cases, those accidental relays or collectors aren't set up to receive syslog messages and will probably just discard them 🗑️. In certain other cases, receiving syslog messages has been known to cause problems for the unintended recipient 😭. If messages aren't reaching the intended recipient, then they can't be reviewed or processed 🥲.
Using a reliable transport mapping can help catch some of these problems ✅. For example, it can spot a message being sent to a system that isn't configured to receive messages 👀. It cannot spot sending messages to a wrong machine that is accepting messages 🙈.
8.10. Forwarding Loop 🔁
As shown in Diagram 2, machines may be configured to relay syslog messages to later relays before they reach a collector 🧚. In one particular case, an admin found that he had mistakenly configured two relays to forward messages with certain SEVERITY values to each other 💀. Whenever either of these machines received or generated that type of message, it would forward it to the other relay, and that relay would forward it right back 🙃. This cycle did cause degradation to the surrounding network as well as to the processing availability on the two devices 📉. Network administrators must take care not to cause such a death spiral ☠️.
8.11. Load Considerations 🏋️♀️
Network administrators must take the time to estimate the right capacity for the syslog collector 📊. An attacker may perform a Denial of Service attack by filling the collector's disk with false messages 😈. Putting the records in a circular file may help with this 🌀, but then there's no guarantee that an admin will be able to review the records later 😬. Along those lines, a transport receiver must have a network interface that's capable of receiving the messages sent to it 📡.
Administrators and network planners must also critically review the network paths between the originators, the relays, and the collectors 🗺️. Generated syslog messages should not overwhelm any of the network links 🚧.
To reduce the impact of this issue, using transports with guaranteed delivery is recommended 💌.
8.12. Denial of Service 🌩️
As with any system, an attacker may just overwhelm a transport receiver by sending it more messages than the infrastructure or the device itself can handle 💥. Implementers should try to provide features that minimize this threat 🛡️, such as only accepting syslog messages from known IP addresses 🎯.
- IANA Considerations 🌸
9.1. VERSION 🔢
IANA has created a registry called "syslog Version Values" for VERSION values, as described in Section 6.2.2 📋. Version numbers MUST be incremented for any new syslog protocol specification that changes any part of the HEADER ⬆️. Changes include adding or removing fields, or changing the syntax or semantics of existing fields 🔧.
VERSION numbers must be registered via the Standards Action method, as described in [RFC5226] 📝. IANA has registered the VERSIONs shown in Table 3 below 👇.
VERSION FORMAT
1 Defined in [RFC5424]
Table 3. IANA-Registered VERSIONs9.2. SD-IDs 🆔
IANA has created a registry called "syslog Structured Data ID Values" for Structured Data ID (SD-ID) values, together with their associated PARAM-NAME values, as described in Section 7 🗂️.
New SD-ID and new PARAM-NAME values must be registered through the IETF Review method, as described in [RFC5226] 🔍.
Once SD-IDs and SD-PARAMs are defined, their syntax and semantics MUST NOT be altered 🚫. Should a change to an existing object be desired, a new SD-ID or SD-PARAM MUST be created and the old one MUST remain unchanged 🫡.
There's a provision here for locally extensible names 🏠. The IANA will not register, and will not control, names with the at-sign (ABNF %d64) in them 🙌.
IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below 📊.
SD-ID PARAM-NAME
timeQuality OPTIONAL
tzKnown OPTIONAL
isSynced OPTIONAL
syncAccuracy OPTIONAL
origin OPTIONAL
ip OPTIONAL
enterpriseId OPTIONAL
software OPTIONAL
swVersion OPTIONAL
meta OPTIONAL
sequenceId OPTIONAL
sysUpTime OPTIONAL
language OPTIONAL
Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs- Working Group 👯♀️
The working group can be contacted via the mailing list 💌:
syslog@ietf.orgThe current Chairs of the Working Group may be contacted at 📧:
Chris Lonvick
Cisco Systems
EMail: clonvick@cisco.com
David Harrington
Huawei Technologies USA
EMail: dbharrington@comcast.net- Acknowledgments 🫶
The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso, and all the other people who commented on various versions of this proposal 💖.
- References 📚
12.1. Normative References 🦋
[ANSI.X3-4.1968] American National Standards Institute, "USA Code
for Information Interchange", ANSI X3.4, 1968.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3418, December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS
Transport Mapping for Syslog", RFC 5425, March
2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages
over UDP", RFC 5426, March 2009.
[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security
Considerations", July 2005.12.2. Informative References 🧠
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.Appendix A. Implementer Guidelines ✨
okay so this whole section is extra advice to help implementers out 💖 it's not normative, which means you are NOT REQUIRED to follow any of it to claim compliance with this spec. vibes only, no pressure 🫶
A.1. Relationship with BSD Syslog 🦋
okay so BSD syslog is literally everywhere, but its format was never formally standardized 💀 [RFC3164] describes the formats people actually observed in the wild. It's an Informational RFC, and there are tons of different implementations out there. The research done while this document was being written showed that different syslog implementations on different platforms have very little in common. The only thing they all agree on is that messages start with "<" PRIVAL ">". Beyond that, legacy syslog messages are not formatted in a consistent way, so RFC 3164 describes no specific elements inside a syslog message. It says that any message sent to the syslog UDP port must be treated as a syslog message, no matter what its format or content is. chaotic but iconic 🌈
This document keeps the PRI value syntax and semantics 🎀 which lets legacy syslog implementations sort messages generated by syslog applications that comply with this specification into the right bins. bestie-approved bridge energy 🌉
Most existing implementations use UDP as the transport protocol for syslog. This specification supports UDP transport but does not recommend it 🙈 Deployment of the required TLS support is recommended. Additional transport protocols may be used ✨
RFC 3164 describes relay behavior. This document does not specify relay behavior. That might be done in a separate document 🧚
The TIMESTAMP described in RFC 3164 is less precise than the timestamp in this document, and it also lacks the year and time zone information 😭 If a message formatted according to this document needs to be reformatted into RFC 3164 format, it is suggested that the originator's local time zone be used, and the time zone information and the year be dropped. If an RFC 3164 formatted message is received and must be transformed to comply with this document, the current year should be added, and the time zone of the relay or collector MAY be used 💅
The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations 💜
The MSG part of the message is described as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. It has been split into APP-NAME, PROCID, and MSGID. This doesn't totally look like the old TAG usage, but it gives the same functionality for most cases 🍓
In RFC 3164, STRUCTURED-DATA was not described. If a message that complies with this document contains STRUCTURED-DATA and must be reformatted according to RFC 3164, the STRUCTURED-DATA simply becomes part of the RFC 3164 CONTENT free-form text 🌸
Overall, this document tries to give you an easily parseable header with clear field separations 👑 whereas traditional BSD syslog suffers from some historically developed, hard-to-parse field separation rules. parsing nightmare, be gone 💀
A.2. Message Length 📏
okay so implementers should note the message size limitations in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length) 🔥 That way the data still gets seen by the collector or relay even if a transport receiver at a relay on the message path truncates the message.
Syslog transport receivers need only support receiving up to and including 480 octets, and that has a lot to do with delivery problems in a broken network 😩 Syslog messages may use a UDP transport mapping with this 480 octet restriction to avoid session overhead and message fragmentation. On a network with problems, one single-packet message is more likely to get delivered successfully than two message fragments are. So a larger size may stop the operator from getting critical info about the problem, while small messages might actually get that info through 🥺 It is recommended that messages intended for troubleshooting not be larger than 480 octets. To back this up, some UDP implementations generally don't support message sizes over 480 octets. This is very rare and may no longer be an issue 🤞
Other use cases send inherently lengthy information, for example audit data 📚 By not enforcing any upper limit on message size, syslog applications can be built with whatever size they need and still comply with this document. In those cases, it is the operator's responsibility to make sure every component in the syslog infrastructure supports the required message sizes. Transport mappings may recommend specific message size limits that must be implemented to comply.
Reminder: message length is specified in octets 🧮 There can be a big difference between the length in characters and the length in octets for UTF-8 strings. the classic gotcha 🙃
It must be noted that the IPv6 MTU is about 2.5 times 480. An implementation aimed at an IPv6-only environment might therefore assume this as a larger minimum size 🌐
A.3. Severity Values 🚨
This section gives guidelines for using Severity as outlined in Section 6.2.1 ✨
All implementations should try to assign the most appropriate severity to their message 💖 Most importantly, messages designed to help debug or test software should be assigned Severity 7. Severity 0 should be reserved for messages of very high importance, like serious hardware failures or an imminent power failure 🔥 An implementation may use Severities 0 and 7 for other purposes if the administrator configures it to.
Severities are very subjective, so a relay or collector should not assume that all originators share the same definition of severity 🤷♀️
A.4. TIME-SECFRAC Precision ⏱️
The TIMESTAMP described in Section 6.2.3 supports fractional seconds. This sets up a super common coding error 😭 where leading zeros get removed from the fractional seconds. For example, the TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as "2003-10-11T22:13:14.3". That would mean 300 milliseconds instead of the 3 milliseconds that were actually meant. the tiniest zero, the biggest chaos 💀
A.5. Case Convention for Names 🐪
Names show up in various places in this document, for example for SD-IDs and PARAM-NAMEs. This document uses "lower camel case" consistently 🌷 That means each name begins with a lower case letter, and each new embedded word starts with an upper case letter, with no hyphen or other delimiter. An example is "timeQuality". so clean 🫧
An implementation is free to use any other case convention for experimental names, but it is suggested that the case convention outlined above is followed 💅
A.6. Syslog Applications Without Knowledge of Time ⏰
In Section 6.2.3, the NILVALUE has been allowed for use by originators without knowledge of time 🙈 This covers a special case where a syslog application isn't aware of time at all. Honestly, it can be argued whether such an application can actually be found in today's IT infrastructure 🤔 However, discussion indicated that these things may exist in practice, so there should be a guideline established for this case.
That said, an implementation SHOULD emit a valid TIMESTAMP if the underlying operating system, programming system, and hardware support a clock function ⭐ A proper TIMESTAMP should be emitted even if it's difficult to obtain the system time. The NILVALUE should only be used when it is actually impossible to obtain time information. This rule should not be used as an excuse for lazy implementations 👀
A.7. Notes on the timeQuality SD-ID 🕰️
It is recommended that the value "0" be the default for the "tzKnown" (Section 7.1.1) parameter. It should only be changed to "1" after the administrator has specifically configured the time zone. The value "1" may be used as the default if the underlying operating system provides accurate time zone information. Even so, it is still advised that the administrator consider how correct the time zone information is 🧐
It's important not to create a false impression of accuracy with the timeQuality SD-ID (Section 7.1) 🚫 An originator should only indicate a given accuracy if it actually knows it is within those bounds. It is generally assumed that the originator gains this in-depth knowledge through operator configuration. By default, an accuracy should not be provided. don't fake your confidence, bestie 💅
A.8. UTF-8 Encoding and the BOM 🌏
This document specifies that SD-PARAMS must always be encoded in UTF-8 💜 Other encodings of the message in the MSG portion, including ASCIIPRINT, are not permitted by a device conforming to this specification. There are two cases to address here 🫶
First, a syslog application conforming to this specification may not be able to determine that the information it gets from an originator is encoded in UTF-8. If it can't determine that with certainty, the syslog application may choose not to include the BOM in the MSG. If the syslog application has a good indication that the message content is encoded in UTF-8, then it should include the BOM ✨
Second, a syslog relay may be forwarding a message from a device that does not conform to this specification. In that case, the device would likely not include the BOM unless it has ascertained that the received message was encoded in UTF-8 🌸
Author's Address 💌
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
Grossrinderfeld, BW 97950
Germany
EMail: rgerhards@adiscon.com📦 where this page comes from
- ietf: rfc5424 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms