    Network Working Group                                        R. Gerhards
    Request for Comments: 5424                                  Adiscon GmbH
    Obsoletes: 3164                                               March 2009
    Category: Standards Track

                              The Syslog Protocol

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  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 in effect on the date of
       publication of this document (http://trustee.ietf.org/license-info).
       Please review these documents carefully, as they describe your rights
       and restrictions with respect to this document.

       This document may contain material from IETF Documents or IETF
       Contributions published or made publicly available before November
       10, 2008.  The person(s) controlling the copyright in some of this
       material may not have granted the IETF Trust the right to allow
       modifications of such material outside the IETF Standards Process.
       Without obtaining an adequate license from the person(s) controlling
       the copyright in such materials, this document may not be modified
       outside the IETF Standards Process, and derivative works of it may
       not be created outside the IETF Standards Process, except to format
       it for publication as an RFC or to translate it into languages other
       than English.

    Gerhards                    Standards Track                     [Page 1]

    RFC 5424                  The Syslog Protocol                 March 2009

    Abstract

       This document describes the syslog protocol, which is used to convey
       event notification messages.  This protocol utilizes a layered
       architecture, which allows the use of any number of transport
       protocols for transmission of syslog messages.  It also provides a
       message format that allows vendor-specific extensions to be provided
       in a structured way.

       This document has been written with the original design goals for
       traditional syslog in mind.  The need for a new layered specification
       has arisen because standardization efforts for reliable and secure
       syslog extensions suffer from the lack of a Standards-Track and
       transport-independent RFC.  Without this document, each other
       standard needs to define its own syslog packet format and transport
       mechanism, which over time will introduce subtle compatibility
       issues.  This document tries to provide a foundation that syslog
       extensions can build on.  This layered architecture approach also
       provides a solid basis that allows code to be written once for each
       syslog feature rather than 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

    Gerhards                    Standards Track                     [Page 2]

    RFC 5424                  The Syslog Protocol                 March 2009

          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 ................................37

    Gerhards                    Standards Track                     [Page 3]

    RFC 5424                  The Syslog Protocol                 March 2009

    1.  Introduction

       This document describes a layered architecture for syslog.  The goal
       of this architecture is to separate message content from message
       transport while enabling easy extensibility for each layer.

       This document describes the standard format for syslog messages and
       outlines the concept of transport mappings.  It also describes
       structured data elements, which can be used to transmit easily
       parseable, structured information, and allows for vendor extensions.

       This document does not describe any storage format for syslog
       messages.  It is beyond of the scope of the syslog protocol and is
       unnecessary for system interoperability.

       This document has been written with the original design goals for
       traditional syslog in mind.  The need for a new layered specification
       has arisen because standardization efforts for reliable and secure
       syslog extensions suffer from the lack of a Standards-Track and
       transport-independent RFC.  Without this document, each other
       standard would need to define its own syslog packet format and
       transport mechanism, which over time will introduce subtle
       compatibility issues.  This document tries to provide a foundation
       that syslog extensions can build on.  This layered architecture
       approach also provides a solid basis that allows code to be written
       once for each syslog feature instead of once for each 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].

    3.  Definitions

       Syslog utilizes three layers:

       o  "syslog content" is the management information contained in a
          syslog message.

       o  The "syslog application" layer handles generation, interpretation,
          routing, and storage of syslog messages.

       o  The "syslog transport" layer puts messages on the wire and takes
          them off the wire.

    Gerhards                    Standards Track                     [Page 4]

    RFC 5424                  The Syslog Protocol                 March 2009

       Certain types of functions are performed at each conceptual layer:

       o  An "originator" generates syslog content to be carried in a
          message.

       o  A "collector" gathers syslog content for further analysis.

       o  A "relay" forwards messages, accepting messages from originators
          or other relays and sending them to collectors or other relays.

       o  A "transport sender" passes syslog messages to a specific
          transport protocol.

       o  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

       The following principles apply to syslog communication:

       o  The syslog protocol does not provide acknowledgment of message
          delivery.  Though some transports may provide status information,
          conceptually, syslog is a pure simplex communications protocol.

       o  Originators and relays may be configured to send the same message
          to multiple collectors and relays.

       o  Originator, relay, and collector functionality may reside on the
          same system.

    Gerhards                    Standards Track                     [Page 5]

    RFC 5424                  The Syslog Protocol                 March 2009

    4.1.  Example Deployment Scenarios

       Sample deployment scenarios are shown in Diagram 2.  Other
       arrangements of these examples are also acceptable.  As noted, in the
       following diagram, relays may send all or some of the messages that
       they receive and also send messages that they generate internally.
       The boxes represent 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|-->--/
                                     +-----+

    Gerhards                    Standards Track                     [Page 6]

    RFC 5424                  The Syslog Protocol                 March 2009

                +----------+         +-----+                   +---------+
                |Originator|---->----|Relay|---->--------------|Collector|
                |          |-+       +-----+                +--|         |
                +----------+  \                            /   +---------+
                               \     +------------+       /
                                \    |+----------+|      /
                                 +->-||Relay     ||->---/
                                     |+----------||    /
                                     ||Originator||->-/
                                     |+----------+|
                                     +------------+

       Diagram 2.  Some Possible Syslog Deployment Scenarios

    5.  Transport Layer Protocol

       This document does not specify any transport layer protocol.
       Instead, it describes the format of a syslog message in a transport
       layer independent way.  Syslog transports are defined in other
       documents.  One such transport is defined in [RFC5426] and is
       consistent with the traditional UDP transport.  This transport is
       needed to maintain interoperability as the UDP transport has
       historically been used for the transmission of syslog messages.

       Any syslog transport protocol MUST NOT deliberately alter the syslog
       message.  If the transport protocol needs to perform temporary
       transformations at the transport sender, these transformations MUST
       be reversed by the transport protocol at the transport receiver so
       that the relay or collector will see an exact copy of the message
       generated by the originator or relay.  Otherwise, end-to-end
       cryptographic verifiers (such as signatures) will be broken.  Of
       course, message alteration might occur due to transmission errors or
       other problems.  Guarding against such alterations is not within the
       scope of this document.

    5.1.  Minimum Required Transport Mapping

       All implementations of this specification MUST support a TLS-based
       transport as described in [RFC5425].

       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.

    Gerhards                    Standards Track                     [Page 7]

    RFC 5424                  The Syslog Protocol                 March 2009

    6.  Syslog Message Format

       The syslog message has the following ABNF [RFC5234] definition:

          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

    Gerhards                    Standards Track                     [Page 8]

    RFC 5424                  The Syslog Protocol                 March 2009

          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

       Syslog message size limits are dictated by the syslog transport
       mapping in use.  There is no upper limit per se.  Each transport
       mapping defines the minimum maximum required message length support,
       and the minimum maximum MUST be at least 480 octets in length.

       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
       receives a message with a length larger than it supports, the
       transport receiver SHOULD truncate the payload.  Alternatively, it
       MAY discard the message.

       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.  The transport
       receiver MAY discard the message or MAY try to process as much as
       possible in this case.

    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
       as defined in "USA Standard Code for Information Interchange"
       [ANSI.X3-4.1968].

       The header format is designed to provide some interoperability with
       older BSD-based syslog.  For details on this, see Appendix A.1.

    6.2.1.  PRI

       The PRI part MUST have three, four, or five characters and will be
       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 followed by a ">" ('greater-than'

    Gerhards                    Standards Track                     [Page 9]

    RFC 5424                  The Syslog Protocol                 March 2009

       character, %d62).  The number contained within these angle brackets
       is known as the Priority value (PRIVAL) and represents both the
       Facility and 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.  They
       are described in the following tables for purely informational
       purposes.  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 Facilities

       Each message Priority also has a decimal Severity level indicator.
       These are described in the following table along with their numerical
       values.  Severity values MUST be in the range of 0 to 7 inclusive.

    Gerhards                    Standards Track                    [Page 10]

    RFC 5424                  The Syslog Protocol                 March 2009

               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 Severities

       The Priority value is calculated by first multiplying the Facility
       number by 8 and 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.  Also, 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, these
       values would be placed 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.

    6.2.2.  VERSION

       The VERSION field denotes the version of the syslog protocol
       specification.  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

       The TIMESTAMP field is a formalized timestamp derived from [RFC3339].

       Whereas [RFC3339] makes allowances for multiple syntaxes, this
       document imposes further restrictions.  The TIMESTAMP value MUST
       follow these restrictions:

       o  The "T" and "Z" characters in this syntax MUST be upper case.

       o  Usage of the "T" character is REQUIRED.

       o  Leap seconds MUST NOT be used.

    Gerhards                    Standards Track                    [Page 11]

    RFC 5424                  The Syslog Protocol                 March 2009

       The originator SHOULD include TIME-SECFRAC if its clock accuracy and
       performance permit.  The "timeQuality" SD-ID described in Section 7.1
       allows the originator to specify the accuracy and trustworthiness of
       the timestamp.

       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.52Z

       This 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:00

       This represents the same time as in example 1, but expressed in US
       Eastern Standard Time (observing daylight savings time).

       Example 3

            2003-10-11T22:14:15.003Z

       This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into
       the next second.  The timestamp is in UTC.  The timestamp provides
       millisecond resolution.  The creator may have actually had a better
       resolution, but providing just three digits for the fractional part
       of a second does not tell us.

       Example 4

             2003-08-24T05:14:15.000003-07:00

       This represents 24 August 2003 at 05:14:15am, 3 microseconds into the
       next second.  The microsecond resolution is indicated by the
       additional digits in TIME-SECFRAC.  The timestamp indicates that its
       local time is -7 hours from UTC.  This timestamp might be created in
       the US Pacific time zone during daylight savings time.

    Gerhards                    Standards Track                    [Page 12]

    RFC 5424                  The Syslog Protocol                 March 2009

       Example 5 - An Invalid TIMESTAMP

             2003-08-24T05:14:15.000000003-07:00

       This example is nearly the same as Example 4, but it is specifying
       TIME-SECFRAC in nanoseconds.  This results in TIME-SECFRAC being
       longer than the allowed 6 digits, which invalidates it.

    6.2.4.  HOSTNAME

       The HOSTNAME field 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.

       In practice, not all syslog applications are able to provide an FQDN.
       As such, other values MAY also be present in HOSTNAME.  This document
       makes provisions for using other values in such 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:

       1.  FQDN

       2.  Static IP address

       3.  hostname

       4.  Dynamic IP address

       5.  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.

       The NILVALUE SHOULD only be used when the syslog application has no
       way to obtain its real hostname.  This situation is considered highly
       unlikely.

    Gerhards                    Standards Track                    [Page 13]

    RFC 5424                  The Syslog Protocol                 March 2009

    6.2.5.  APP-NAME

       The APP-NAME field SHOULD identify the device or application that
       originated the message.  It is a string without further semantics.
       It is intended 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.  It may be that a
       device is unable to provide that information either 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 that is included in the message, having no
       interoperable meaning, except that a change in the value indicates
       there has been a discontinuity in syslog reporting.  The field does
       not 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.

       The PROCID field 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 is not available.  On an embedded system without any
       operating system process ID, PROCID might be a reboot ID.

       PROCID can enable log analyzers to detect discontinuities in syslog
       reporting by detecting a change in the syslog process ID.  However,
       PROCID is not a reliable identification of a restarted process since
       the restarted syslog process might be assigned the same process ID as
       the previous syslog process.

       PROCID can also be used to identify which messages belong to a group
       of messages.  For example, an SMTP mail transfer agent might put its
       SMTP transaction ID into PROCID, which would allow the collector or
       relay to group messages based on the 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 the
       MSGID "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 is intended for filtering
       messages on a relay or collector.

    Gerhards                    Standards Track                    [Page 14]

    RFC 5424                  The Syslog Protocol                 March 2009

       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 provides a mechanism to express information in a well
       defined, easily parseable and interpretable data format.  There are
       multiple usage scenarios.  For example, it may express meta-
       information about the syslog message or application-specific
       information such as traffic counters or IP addresses.

       STRUCTURED-DATA can contain zero, one, or multiple structured data
       elements, which are referred to as "SD-ELEMENT" in this document.

       In case of 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 as defined in "USA Standard Code for Information Interchange"
       [ANSI.X3-4.1968].  An exception is the PARAM-VALUE field (see
       Section 6.3.3), in which UTF-8 encoding MUST be used.

       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 consists of a name and parameter name-value pairs.  The
       name is referred to as SD-ID.  The name-value pairs are referred to
       as "SD-PARAM".

    6.3.2.  SD-ID

       SD-IDs are case-sensitive and 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:

       o  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

    Gerhards                    Standards Track                    [Page 15]

    RFC 5424                  The Syslog Protocol                 March 2009

          %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).

       o  Anyone can define additional SD-IDs using names in the format
          name@<private enterprise number>, e.g., "ourSDID@32473".  The
          format of the part preceding 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 following
          the at-sign MUST be a private enterprise number as specified in
          Section 7.2.2.  Please note that throughout this document the
          value of 32473 is used for all private enterprise numbers.  This
          value has been reserved by IANA to be used as an example number in
          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 consists of a name, referred to as PARAM-NAME, and a
       value, referred to as PARAM-VALUE.

       PARAM-NAME is case-sensitive.  IANA controls all PARAM-NAMEs, with
       the exception of those in SD-IDs whose names contain an at-sign.  The
       PARAM-NAME scope is within a specific SD-ID.  Thus, equally named
       PARAM-NAME values contained in two different SD-IDs are not the same.

       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 (e.g., 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 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

    Gerhards                    Standards Track                    [Page 16]

    RFC 5424                  The Syslog Protocol                 March 2009

       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, syntax and semantics of
       these objects MUST NOT be altered.  Should a change to an existing
       object be desired, a new SD-ID or PARAM-NAME MUST be created and the
       old one remain unchanged.  OPTIONAL PARAM-NAMEs MAY be added to an
       existing SD-ID.

    6.3.5.  Examples

       All examples in this section show only the structured data part of
       the message.  Examples should be considered to be on one line.  They
       are wrapped on multiple lines in this document for readability
       purposes.  A description is given after each example.

       Example 1 - Valid

               [exampleSDID@32473 iut="3" eventSource="Application"
               eventID="1011"]

       This example is a structured data element with a non-IANA controlled
       SD-ID of type "exampleSDID@32473", which has three parameters.

       Example 2 - Valid

               [exampleSDID@32473 iut="3" eventSource="Application"
               eventID="1011"][examplePriority@32473 class="high"]

       This is the same example as in 1, but with a second structured data
       element.  Please note that the structured data element immediately
       follows the first one (there is no SP between them).

       Example 3 - Invalid

               [exampleSDID@32473 iut="3" eventSource="Application"
               eventID="1011"] [examplePriority@32473 class="high"]

    Gerhards                    Standards Track                    [Page 17]

    RFC 5424                  The Syslog Protocol                 March 2009

       This is nearly the same example as 2, but it has a subtle error --
       there is an SP character between the two structured data elements
       ("]SP[").  This is invalid.  It will cause the STRUCTURED-DATA field
       to end after the first element.  The second element will be
       interpreted as part of the MSG field.

       Example 4 - Invalid

               [ exampleSDID@32473 iut="3" eventSource="Application"
               eventID="1011"][examplePriority@32473 class="high"]

       This example is nearly the same as 2.  It has another subtle error --
       the SP character occurs after the initial bracket.  A structured data
       element SD-ID MUST immediately follow the beginning bracket, so the
       SP character invalidates the STRUCTURED-DATA.  A syslog application
       MAY discard this message.

       Example 5 - Valid

               [sigSig ver="1" rsID="1234" ... signature="..."]

       Example 5 is a valid example.  It shows a hypothetical IANA-assigned
       SD-ID.  The ellipses denote missing content, which has been left out
       of this example for brevity.

    6.4.  MSG

       The MSG part contains a free-form message that provides information
       about the event.

       The character set used in MSG SHOULD be UNICODE, encoded using UTF-8
       as specified in [RFC3629].  If the syslog application cannot encode
       the MSG in Unicode, it MAY use any other encoding.

       The syslog application SHOULD avoid octet values below 32 (the
       traditional US-ASCII control character range except DEL).  These
       values are legal, but a syslog application MAY modify these
       characters upon reception.  For example, it might change them into an
       escape sequence (e.g., value 0 may be changed to "\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), which for UTF-8 is ABNF
       %xEF.BB.BF.  The syslog application MUST encode in the "shortest
       form" and MAY use any valid UTF-8 sequence.

    Gerhards                    Standards Track                    [Page 18]

    RFC 5424                  The Syslog Protocol                 March 2009

       If a syslog application is processing an MSG starting with a BOM and
       the MSG contains UTF-8 that is not shortest form, the MSG MUST NOT be
       interpreted as being encoded in UTF-8, for the reasons outlined in
       [UNICODE-TR36], Section 3.1.  Guidance about this is given 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.

    6.5.  Examples

       The following are examples of valid syslog messages.  A description
       of each example can be found below it.  The examples are based on
       similar examples from [RFC3164] and may be familiar to readers.  The
       otherwise-unprintable Unicode BOM is represented as "BOM" in the
       examples.

       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/8

       In this example, the VERSION is 1 and the Facility has the value of
       4.  The Severity is 2.  The message was created on 11 October 2003 at
       10:14:15pm UTC, 3 milliseconds into the next second.  The message
       originated from a host that identifies itself as
       "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.  The encoding is defined by the BOM.
       There is no STRUCTURED-DATA present in the message; this is indicated
       by "-" in the STRUCTURED-DATA field.

       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.

       In this example, the VERSION is again 1.  The Facility is 20, the
       Severity 5.  The message 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", so the syslog application did not know
       its FQDN and used one of its IPv4 addresses instead.  The APP-NAME is
       "myproc" and the PROCID is "8710" (for example, this could be the
       UNIX PID).  There is no STRUCTURED-DATA present in the message; this
       is indicated by "-" in the STRUCTURED-DATA field.  There is no
       specific MSGID and this is indicated by the "-" in the MSGID field.

    Gerhards                    Standards Track                    [Page 19]

    RFC 5424                  The Syslog Protocol                 March 2009

       The message is "%% It's time to make the do-nuts.".  As the Unicode
       BOM is missing, the syslog application does not know the encoding of
       the MSG part.

       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 example is modeled after Example 1.  However, this time it
       contains 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 beginning of MSG indicates UTF-8 encoding.

       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 example shows a message with only STRUCTURED-DATA and no MSG
       part.  This is a valid message.

    7.  Structured Data IDs

       This section defines the initial IANA-registered SD-IDs.  See
       Section 6.3 for a definition of structured data elements.  All SD-IDs
       defined here are OPTIONAL.

       In some of the following, a maximum length is quantified for the
       parameter values.  In each of those cases, the syslog application
       MUST be prepared to receive the number of defined characters in any
       valid UTF-8 code point.  Since each character may be up to 6 octets,
       it is RECOMMENDED that each syslog application be prepared to receive
       up to 6 octets per character.

    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 is not properly synchronized with a reliable external time
       source or if it does not know whether its time zone information is

    Gerhards                    Standards Track                    [Page 20]

    RFC 5424                  The Syslog Protocol                 March 2009

       correct.  The main use of this structured data element is to provide
       some information on the level of trust it has in the TIMESTAMP
       described in Section 6.2.3.  All parameters are OPTIONAL.

    7.1.1.  tzKnown

       The "tzKnown" parameter indicates 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.  If the
       originator knows its time zone but decides to emit time in UTC, the
       value "1" MUST be used (because the time zone is known).

    7.1.2.  isSynced

       The "isSynced" parameter indicates whether the originator is
       synchronized to a reliable external time source, e.g., 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 indicates how accurate the originator
       thinks its time synchronization is.  It is an integer describing the
       maximum number of microseconds that its clock may be off between
       synchronization intervals.

       If the value "0" is used for "isSynced", this parameter MUST NOT be
       specified.  If the value "1" is used for "isSynced" but the
       "syncAccuracy" parameter is absent, a collector or relay can assume
       that the time information provided is accurate enough to be
       considered correct.  The "syncAccuracy" parameter MUST be written
       only if the originator actually has knowledge of the reliability of
       the external time source.  In most cases, it will gain this in-depth
       knowledge through operator configuration.

    7.1.4.  Examples

       The following is an example of an originator that does not know its
       time zone or whether it is being synchronized:

       [timeQuality tzKnown="0" isSynced="0"]

       With this information, the originator indicates that its time
       information is unreliable.  This may be a hint for the collector or
       relay to use its local time instead of the message-provided TIMESTAMP
       for correlation of multiple messages from different originators.

    Gerhards                    Standards Track                    [Page 21]

    RFC 5424                  The Syslog Protocol                 March 2009

       The following is an example of an originator that knows its time zone
       and knows that it is properly synchronized to a reliable external
       source:

       [timeQuality tzKnown="1" isSynced="1"]

       The following is an example of an originator that knows both its time
       zone and that it is externally synchronized.  It also knows the
       accuracy of the external synchronization:

       [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]

       The difference between this and the previous example is that the
       originator expects that its clock will be kept within 60 seconds of
       the official time.  Thus, if the originator reports it is 9:00:00, it
       is no earlier than 8:59:00 and no later then 9:01:00.

    7.2.  origin

       The SD-ID "origin" MAY be used to indicate the origin of a syslog
       message.  The following parameters can be used.  All parameters are
       OPTIONAL.

       Specifying any of these parameters is primarily an aid to log
       analyzers and similar applications.

    7.2.1.  ip

       The "ip" parameter denotes an IP address that the originator knows it
       had at the time of originating the message.  It MUST contain the
       textual representation of an IP address as outlined in Section 6.2.4.

       This parameter can be used to provide identifying information in
       addition to what is present in the HOSTNAME field.  It might be
       especially useful if the host's IP address is included in the message
       while the HOSTNAME field still contains the FQDN.  It is also useful
       for describing all IP addresses of a multihomed host.

       If an originator has multiple IP addresses, it MAY either list one of
       its IP addresses 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).  The number
       that follows MUST be unique and MUST be registered with IANA as per

    Gerhards                    Standards Track                    [Page 22]

    RFC 5424                  The Syslog Protocol                 March 2009

       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.

    Gerhards                    Standards Track                    [Page 23]

    RFC 5424                  The Syslog Protocol                 March 2009

    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].

    8.  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

    Gerhards                    Standards Track                    [Page 24]

    RFC 5424                  The Syslog Protocol                 March 2009

       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.

    Gerhards                    Standards Track                    [Page 25]

    RFC 5424                  The Syslog Protocol                 March 2009

    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.

    Gerhards                    Standards Track                    [Page 26]

    RFC 5424                  The Syslog Protocol                 March 2009

       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

       Because syslog can generate unlimited amounts of data, transferring
       this data over UDP is generally problematic, because UDP lacks
       congestion control mechanisms.  Congestion control mechanisms that
       respond to congestion by reducing traffic rates and establish a
       degree of fairness between flows that share the same path are vital
       to the stable operation of the Internet [RFC2914].  This is why the
       syslog TLS transport 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
       SHOULD be used.

       In any implementation, the situation may arise in which an originator
       or relay would need to block sending messages.  A common case is when
       an internal queue is full.  This might happen due to rate-limiting or
       slow performance of the syslog application.  In any event, it is
       highly RECOMMENDED that no messages be dropped but that they should
       be temporarily stored until they can be transmitted.  However, if
       they must be dropped, it is RECOMMENDED that the originator or relay
       drop messages of lower severity in favor of higher severity messages.

    Gerhards                    Standards Track                    [Page 27]

    RFC 5424                  The Syslog Protocol                 March 2009

       Messages with a lower numerical SEVERITY value have a higher
       practical severity than those with a numerically higher value.  In
       that situation, the messages that are to be dropped SHOULD simply be
       discarded.  The syslog application may notify a collector or relay
       about the fact that it has dropped messages.

    8.7.  Message Integrity

       Besides being discarded, syslog messages may be damaged in transit,
       or an attacker may maliciously modify them.  In such cases, the
       original contents of the message will not be delivered to the
       collector or relay.  Additionally, if an attacker is positioned
       between the transport sender and transport receiver of syslog
       messages, they may be able to intercept and modify those messages
       while in-transit to hide unauthorized activities.

    8.8.  Message Observation

       While there are no strict guidelines pertaining to the MSG format,
       most syslog messages are generated in human-readable form with the
       assumption that capable administrators should be able to read them
       and understand their meaning.  The syslog protocol does not have
       mechanisms to provide confidentiality for the messages in transit.
       In most cases, passing clear-text messages is a benefit to the
       operations staff if they are sniffing the packets from the wire.  The
       operations staff may be able to read the messages and associate them
       with other events seen from other packets crossing the wire to track
       down and correct problems.  Unfortunately, an attacker may also be
       able to observe the human-readable contents of syslog messages.  The
       attacker may then use the knowledge gained 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 wholly the responsibility of the
       network administrator to ensure that the messages are actually going
       to the intended recipients.  Cases have been noted where syslog
       applications were inadvertently configured to send syslog messages to
       the wrong relays or collectors.  In many cases, the inadvertent
       relays or collectors may not be configured to receive syslog messages
       and will probably discard them.  In certain other cases, the receipt
       of syslog messages has been known to cause problems for the
       unintended recipient.  If messages are not going to the intended
       recipient, then they cannot be reviewed or processed.

    Gerhards                    Standards Track                    [Page 28]

    RFC 5424                  The Syslog Protocol                 March 2009

       Using a reliable transport mapping can help identify some of these
       problems.  For example, it can identify a problem where a message is
       being sent to a system that is not configured to receive messages.
       It cannot identify 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 subsequent relays before reaching a collector.  In one
       particular case, an administrator found that he had mistakenly
       configured two relays to forward messages with certain SEVERITY
       values to each other.  When either of these machines either received
       or generated that type of message, it would forward it to the other
       relay.  That relay would, in turn, forward it back.  This cycle did
       cause degradation to the intervening 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 appropriate
       capacity of the syslog collector.  An attacker may perform a Denial
       of Service attack by filling the disk of the collector with false
       messages.  Placing the records in a circular file may alleviate this
       but has the consequence of not ensuring that an administrator will be
       able to review the records in the future.  Along this line, a
       transport receiver must have a network interface 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.

       In order 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 more messages to it than can be handled by the
       infrastructure or the device itself.  Implementers should attempt to
       provide features that minimize this threat, such as only accepting
       syslog messages from known IP addresses.

    Gerhards                    Standards Track                    [Page 29]

    RFC 5424                  The Syslog Protocol                 March 2009

    9.  IANA Considerations

    9.1.  VERSION

       IANA has created a registry entitled "syslog Version Values" of
       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 addition or removal of
       fields or a change of 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 VERSIONs

    9.2.  SD-IDs

       IANA has created a registry entitled "syslog Structured Data ID
       Values" of 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, syntax and semantics of these
       objects 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
       remain unchanged.

       A provision is made 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

    Gerhards                    Standards Track                    [Page 30]

    RFC 5424                  The Syslog Protocol                 March 2009

           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

    10.  Working Group

       The working group can be contacted via the mailing list:

             syslog@ietf.org

       The 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

    11.  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.

    Gerhards                    Standards Track                    [Page 31]

    RFC 5424                  The Syslog Protocol                 March 2009

    12.  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.

    Gerhards                    Standards Track                    [Page 32]

    RFC 5424                  The Syslog Protocol                 March 2009

       [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.

    Gerhards                    Standards Track                    [Page 33]

    RFC 5424                  The Syslog Protocol                 March 2009

    Appendix A.  Implementer Guidelines

       Information in this section is given as an aid to implementers.
       While this information is considered to be helpful, it is not
       normative.  As such, an implementation is NOT REQUIRED to follow it
       in order to claim compliance to this specification.

    A.1.  Relationship with BSD Syslog

       While BSD syslog is in widespread use, its format has never been
       formally standardized.  [RFC3164] describes observed formats.  It is
       an Informational RFC, and practice shows that there are many
       different implementations.  Research during creation of this document
       showed that there is very little in common between different syslog
       implementations on different platforms.  The only thing that all of
       them agree upon is that messages start with "<" PRIVAL ">".  Other
       than that, legacy syslog messages are not formatted in a consistent
       way.  Consequently, RFC 3164 describes no specific elements inside a
       syslog message.  It states that any message destined to the syslog
       UDP port must be treated as a syslog message, no matter what its
       format or content is.

       This document retains the PRI value syntax and semantics.  This will
       allow legacy syslog implementations to put messages generated by
       syslog applications compliant to this specification into the right
       bins.

       Most existing implementations support 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.  This might be done in a separate document.

       The TIMESTAMP described in RFC 3164 offers less precision than the
       timestamp specified in this document.  It also lacks the year and
       time zone information.  If a message formatted according to this
       document needs to be reformatted to be in 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 be compliant to 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.

    Gerhards                    Standards Track                    [Page 34]

    RFC 5424                  The Syslog Protocol                 March 2009

       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.  The
       TAG has been split into APP-NAME, PROCID, and MSGID.  This does not
       totally resemble the usage of TAG, but provides the same
       functionality for most of the cases.

       In RFC 3164, STRUCTURED-DATA was not described.  If a message
       compliant 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.

       In general, this document tries to provide an easily parseable header
       with clear field separations, whereas traditional BSD syslog suffers
       from some historically developed, hard to parse field separation
       rules.

    A.2.  Message Length

       Implementers should note the message size limitations outlined in
       Section 6.1 and try to keep the most important data early in the
       message (within the minimum guaranteed length).  This ensures the
       data will be seen by the collector or relay even if a transport
       receiver at a relay on the message path truncates the message.

       The reason syslog transport receivers need only support receiving up
       to and including 480 octets has, among other things, to do with
       difficult 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.  In a network with
       problems, the likelihood of getting one single-packet message
       delivered successfully is higher than getting two message fragments
       delivered successfully.  Therefore, using a larger size may prevent
       the operator from getting some critical information about the
       problem, whereas using small messages might get that information to
       the operator.  It is recommended that messages intended for
       troubleshooting purposes should not be larger than 480 octets.  To
       further strengthen this point, it has also been observed that some
       UDP implementations generally do not support message sizes of more
       than 480 octets.  This behavior is very rare and may no longer be an
       issue.

       There are other use cases where syslog messages are used to transmit
       inherently lengthy information, e.g., audit data.  By not enforcing
       any upper limit on the message size, syslog applications can be
       implemented with any size needed and still be compliant with this
       document.  In such cases, it is the operator's responsibility to

    Gerhards                    Standards Track                    [Page 35]

    RFC 5424                  The Syslog Protocol                 March 2009

       ensure that all components in a syslog infrastructure support the
       required message sizes.  Transport mappings may recommend specific
       message size limits that must be implemented to be compliant.

       Implementers are reminded that the message length is specified in
       octets.  There is a potentially large difference between the length
       in characters and the length in octets for UTF-8 strings.

       It must be noted that the IPv6 MTU is about 2.5 times 480.  An
       implementation targeted towards an IPv6-only environment might thus
       assume this as a larger minimum size.

    A.3.  Severity Values

       This section describes 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
       enable debugging or testing of software should be assigned Severity
       7.  Severity 0 should be reserved for messages of very high
       importance (like serious hardware failures or imminent power
       failure).  An implementation may use Severities 0 and 7 for other
       purposes if this is configured by the administrator.

       Because severities are very subjective, a relay or collector should
       not assume that all originators have the same definition of severity.

    A.4.  TIME-SECFRAC Precision

       The TIMESTAMP described in Section 6.2.3 supports fractional seconds.
       This provides grounds for a very common coding error, where leading
       zeros are 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".  This would indicate 300 milliseconds
       instead of the 3 milliseconds actually meant.

    A.5.  Case Convention for Names

       Names are used at various places in this document, for example for
       SD-IDs and PARAM-NAMEs.  This document uses "lower camel case"
       consistently.  With that, 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 of this is "timeQuality".

       While an implementation is free to use any other case convention for
       experimental names, it is suggested that the case convention outlined
       above is followed.

    Gerhards                    Standards Track                    [Page 36]

    RFC 5424                  The Syslog Protocol                 March 2009

    A.6.  Syslog Applications Without Knowledge of Time

       In Section 6.2.3, the NILVALUE has been allowed for usage by
       originators without knowledge of time.  This is done to support a
       special case when a syslog application is not aware of time at all.
       It can be argued whether such a syslog application can actually be
       found in today's IT infrastructure.  However, discussion has
       indicated that those things may exist in practice and as such there
       should be a guideline established for this case.

       However, an implementation SHOULD emit a valid TIMESTAMP if the
       underlying operating system, programming system, and hardware
       supports a clock function.  A proper TIMESTAMP should be emitted even
       if it is 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 of "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.  It is
       still advised that the administrator consider the correctness of the
       time zone information.

       It is 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 these bounds.  It
       is generally assumed that the originator gains this in-depth
       knowledge through operator configuration.  By default, an accuracy
       should not be provided.

    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 that need to be addressed here.
       First, a syslog application conforming to this specification may not
       be able to ascertain that the information given to it from an
       originator is encoded in UTF-8.  If it cannot determine that with
       certainty, the syslog application may choose to not incorporate the
       BOM in the MSG.  If the syslog application has a good indication that
       the content of the message is encoded in UTF-8, then it should
       include the BOM.  In the second case, a syslog relay may be

    Gerhards                    Standards Track                    [Page 37]

    RFC 5424                  The Syslog Protocol                 March 2009

       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

    Gerhards                    Standards Track                    [Page 38]