[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 RFC 5424

syslog Working Group                                         R. Gerhards
Internet-Draft                                              Adiscon GmbH
Expires: August 16, 2004                               February 16, 2004

                          The syslog Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 16, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   This document describes the syslog protocol. The syslog protocol has
   been used throughout the years to convey event notifications. This
   documents describes a layered architecture for an easily extensible
   syslog protocol. It also describes the basic message format and
   structured elements used to provide meta-information about the

Gerhards                Expires August 16, 2004                 [Page 1]

Internet-Draft            The syslog Protocol              February 2004

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Definitions and Architecture . . . . . . . . . . . . . . . .  5
   3.    Transport Layer Protocol . . . . . . . . . . . . . . . . . .  8
   3.1   Minimum Required Transport Mapping . . . . . . . . . . . . .  8
   4.    Required syslog Format . . . . . . . . . . . . . . . . . . .  9
   4.1   HEADER Part  . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1.1 VERSION  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1.2 enterpriseID . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.1.3 FACILITY . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.4 SEVERITY . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1.5 TIMESTAMP  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.1.6 HOSTNAME . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.1.7 TAG  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.2   MSG  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.3   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.    Structured Data  . . . . . . . . . . . . . . . . . . . . . . 19
   5.1   Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.2   MSG with just Structured Data  . . . . . . . . . . . . . . . 21
   5.3   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   6.    Multi-Part Messages  . . . . . . . . . . . . . . . . . . . . 23
   6.1   Definitions  . . . . . . . . . . . . . . . . . . . . . . . . 23
   6.1.1 Original Message . . . . . . . . . . . . . . . . . . . . . . 23
   6.1.2 Message Part . . . . . . . . . . . . . . . . . . . . . . . . 23
   6.1.3 Message Disassembly and Reassembly . . . . . . . . . . . . . 23
   6.1.4 Multi-Part Message Header  . . . . . . . . . . . . . . . . . 23
   6.1.5 Message Part Message . . . . . . . . . . . . . . . . . . . . 23
   6.1.6 Multi-Part Messaging . . . . . . . . . . . . . . . . . . . . 24
   6.2   SD-ID msgpart  . . . . . . . . . . . . . . . . . . . . . . . 24
   6.2.1 msgid  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.2.2 partnum  . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.2.3 partcount  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   6.3   Cryptographically Signing Multi-Part Messages  . . . . . . . 26
   6.4   Multi-Part Message Examples  . . . . . . . . . . . . . . . . 27
   7.    Structured Data IDs  . . . . . . . . . . . . . . . . . . . . 29
   7.1   msgpart  . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   7.2   time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   7.2.1 tzknown  . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   7.2.2 issynced . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   7.2.3 syncaccuracy . . . . . . . . . . . . . . . . . . . . . . . . 30
   7.2.4 Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   7.3   origin . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   7.3.1 format . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   7.3.2 ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   7.3.3 Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   8.    Relay Operations . . . . . . . . . . . . . . . . . . . . . . 33
   8.1   No Message Modification Allowed  . . . . . . . . . . . . . . 33

Gerhards                Expires August 16, 2004                 [Page 2]

Internet-Draft            The syslog Protocol              February 2004

   8.2   RFC 3164 Messages  . . . . . . . . . . . . . . . . . . . . . 33
   8.2.1 Reception of RFC 3164 Messages . . . . . . . . . . . . . . . 33
   8.2.2 Sending RFC 3164 Messages  . . . . . . . . . . . . . . . . . 33
   8.3   Creation of Multi-Part Messages  . . . . . . . . . . . . . . 33
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 34
   9.1   Diagnostic Logging . . . . . . . . . . . . . . . . . . . . . 34
   9.2   Packet Parameters  . . . . . . . . . . . . . . . . . . . . . 35
   9.3   Single Source to a Destination . . . . . . . . . . . . . . . 36
   9.4   Multiple Sources to a Destination  . . . . . . . . . . . . . 36
   9.5   Multiple Sources to Multiple Destinations  . . . . . . . . . 36
   9.6   Replaying  . . . . . . . . . . . . . . . . . . . . . . . . . 37
   9.7   Reliable Delivery  . . . . . . . . . . . . . . . . . . . . . 37
   9.8   Message Integrity  . . . . . . . . . . . . . . . . . . . . . 38
   9.9   Message Observation  . . . . . . . . . . . . . . . . . . . . 38
   9.10  Misconfiguration . . . . . . . . . . . . . . . . . . . . . . 38
   9.11  Forwarding Loop  . . . . . . . . . . . . . . . . . . . . . . 39
   9.12  Load Considerations  . . . . . . . . . . . . . . . . . . . . 39
   9.13  Denial of Service  . . . . . . . . . . . . . . . . . . . . . 39
   9.14  Covert Channels  . . . . . . . . . . . . . . . . . . . . . . 39
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 40
   11.   Authors and Working Group Chair  . . . . . . . . . . . . . . 41
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
         References . . . . . . . . . . . . . . . . . . . . . . . . . 43
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 43
         Intellectual Property and Copyright Statements . . . . . . . 44

Gerhards                Expires August 16, 2004                 [Page 3]

Internet-Draft            The syslog Protocol              February 2004

1. Introduction

   This document describes the semantics of the syslog protocol,
   outlines transport mappings and provides a standard format for all
   syslog messages. It also describes structured data elemtns, that can
   be used to precisely define specific message aspects. Many of these
   structured data elements carry optional information and are as such
   optional themselves.

   This document describes a layered architecture for syslog. The goal
   of this architecture is to separate the functionality into separate
   layers and thus provide easy extensibility.

   While REQUIRING A specific format for syslog messages, the document
   acknowledges the importance of interoperability with existing syslog
   implementations.  The informational document RFC 3164 [10] describes
   a general format of syslog messages as they have been seen on the
   wire. In order to be interoperable with existing implementations,
   this document RECOMMENDS a set of mappings between the RFC 3164
   format and the format outlined herein. These mappings MAY be done by
   relays. It is NOT the intention that an implementation implementing
   this document can itself send to a RFC 3164 implementation. Neither
   is an implementation of this document expected or required to
   directly receive messages from a RFC 3164 implementation. The mapping
   rules only apply to relays, which then can actually be used as
   gateways between implementations of this document and RFC 3164.

   In order to claim compliance with this document, an implementation
   MUST at least implement all REQUIRED parts. Optional parts must not
   necessarily be implemented. Most importantly, RFC 3164
   interoperability is NOT a REQUIRED part of this document.

Gerhards                Expires August 16, 2004                 [Page 4]

Internet-Draft            The syslog Protocol              February 2004

2. Definitions and Architecture

   The following definitions will be used in this document.

      A machine that can generate a message will be called a "device".

      A machine that can receive the message and forward it to another
      machine will be called a "relay".

      A machine that receives the message and does not relay it to any
      other machines will be called a "collector".  This has been
      commonly known as a "syslog server".

      Any device or relay will be known as the "sender" when it sends a

      Any relay or collector will be known as the "receiver" when it
      receives the message.

      There are machines that both receive messages and forward them to
      another machine AND generate syslog messages themselfs. An example
      for this may be an application that operates as a syslog relay as
      one service while at the same time running other services. These
      services may be monitored by the same application, generating new
      syslog messages. Such a machine acts both as a relay AND a device.
      This case is specifically mentioned as the role a machine plays
      has special significance, for example on formatting. A machine as
      described here may thus have two separate configurations for each
      of the machine's operations modes.

   The architecture of the devices may be summarized as follows:

      Senders send messages to relays or collectors with no knowledge of
      whether it is a collector or relay.

      Senders may be configured to send the same message to multiple

      Relays may send all or some of the messages that they receive to a
      subsequent relay or collector.  In the case where they do not
      forward all of their messages, they are acting as both a collector
      and a relay.  In the following diagram, these devices will be
      designated as relays.

      Relays may also generate their own messages and send them on to
      subsequent relays or collectors.  In that case it is acting as a
      device.  These devices will also be designated as a relay in the
      following diagram.

Gerhards                Expires August 16, 2004                 [Page 5]

Internet-Draft            The syslog Protocol              February 2004

   The following architectures shown in Diagram 1 are valid while the
   first one has been known to be the most prevalent.  Other
   arrangements of these examples are also acceptable.  As noted above,
   in the following diagram relays may pass along all or some of the
   messages that they receive along with passing along messages that
   they internally generate.

            +------+         +---------+
            +------+         +---------+

            +------+         +-----+         +---------+
            +------+         +-----+         +---------+

            +------+     +-----+            +-----+     +---------+
            +------+     +-----+            +-----+     +---------+

            +------+         +-----+         +---------+
            |      |-\       +-----+         +---------+
            +------+  \
                       \      +-----+         +---------+
                              +-----+         +---------+

            +------+         +---------+
            |      |-\       +---------+
            +------+  \
                       \      +-----+         +---------+
                              +-----+         +---------+

            +------+         +-----+            +---------+
            |      |-\       +-----+         /--|         |
            +------+  \                     /   +---------+
                       \      +-----+      /

Gerhards                Expires August 16, 2004                 [Page 6]

Internet-Draft            The syslog Protocol              February 2004

            +------+          +-----+               +---------+
            |      |-\        +-----+            /--|         |
            +------+  \                         /   +---------+
                       \      +--------+       /
                        \     |+------+|      /
                         \-->-||Relay ||->---/
                              |+------||    /

   Diagram 1.  Some Possible syslog Architectures

Gerhards                Expires August 16, 2004                 [Page 7]

Internet-Draft            The syslog Protocol              February 2004

3. Transport Layer Protocol

   This document DOES NOT specify a specific transport layer protocol.
   Instead, it describes the format of a syslog message in a transport
   layer independent way.

   Transport mappings being defined MUST ensure that a message formatted
   according to this document can be transmitted unaltered over the
   mapping. If the mapping needs to perform temporary transformations,
   it must be guaranteed that the message received at the final
   destination is an exact copy of the message sent from the initial
   originator. This is vital because otherwise cryptographic verifiers
   (like signatures) would be broken.

3.1 Minimum Required Transport Mapping

   To claim compliance with this document, each implementation MUST at
   least implement the UDP transport mapping described in Anton
   Okmianski "Syslog over UDP" (draft-ietf-syslog-udp-transport-00.txt).
   This is to ensure a minimum interoperability between systems
   implementing this document.

Gerhards                Expires August 16, 2004                 [Page 8]

Internet-Draft            The syslog Protocol              February 2004

4. Required syslog Format

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

      ; The general syslog message format


      HEADER          = "V" VERSION SP enterpriseID SP FACILITY SP
      VERSION         = 1*3DIGIT
      enterpriseID    = 1*10DIGIT  ; range 0..2147483648
      FACILITY        = 1*10DIGIT  ; range 0..2147483648
      SEVERITY        = "0" / "1" / "2" / "3" / "4" / "5" /
                        "6" / "7"
      HOSTNAME        = 1*255PRINTUSASCII  ; a FQDN

      TAG             = static-id  [full-dyn-id] [":"] ; 64 chars max
      static-id       = 1*VISUAL
      full-dyn-id     = "[" proc-id [thread-sep thread-id] "]"
      proc-id         = 1*ALFANUM  ; recommended: number
      thread-sep      = VISUAL / %d58     ; recommended: ",", or ':', or '.'
      thread-id       = 1*ALFANUM  ; recommended: number
      VISUAL          = (%d33-57/%d59-126) ; all but SP and ":"

      TIMESTAMP       = full-date "T" full-time
      date-fullyear   = 4DIGIT
      date-month      = 2DIGIT  ; 01-12
      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                                ; month/year
      time-hour       = 2DIGIT  ; 00-23
      time-minute     = 2DIGIT  ; 00-59
      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap
                                ; second rules
      time-secfrac    = "." 1*6DIGIT
      time-offset     = "Z" / time-numoffset
      time-numoffset  = ("+" / "-") time-hour ":" time-minute

      partial-time    = time-hour ":" time-minute ":" time-second
      full-date       = date-fullyear "-" date-month "-" date-mday
      full-time       = partial-time time-offset

      MSG             = *OCTECT
                        ; VALID UTF-8 String of PRINTABLE characters
      OCTET           = %d00..255
      LF              = %d10
      CR              = %d13

Gerhards                Expires August 16, 2004                 [Page 9]

Internet-Draft            The syslog Protocol              February 2004

      SP              = %d32
      PRINTUSASCII    = %d33-126
      ALFANUM         = %d48..57 / %d65..90 / %d97..122

4.1 HEADER Part

   The header MUST contain the token identifying the message as a syslog
   message complying with this specification, the version of the
   specification it complies to, the enterpriseID of the original
   sender, the facility, the severity, the timestamp, the hostname and
   the tag. Each of this fields MUST be present and MUST be of correct
   syntax. The code set used in the HEADER MUST be seven-bit ASCII in an
   eight-bit field as described in RFC 2234 [7]. These are the ASCII
   codes as defined in "USA Standard Code for Information Interchange"
   ANSI.X3-4.1968 [1].

   If the header is not syntactically correct, the receiver MUST NOT try
   to sub-parse some of the header fields in order to find a "good"
   interpretation. However, the receiver MAY assume it is a RFC3164
   compliant message and MAY decide to process it as such. In this case,
   RFC3164 semantics MUST be used.

   As a note to implementors, the "V" token at the very beginning of the
   message MAY be used as a rough indication whether or not the message
   complies to this document. However, it is not sufficient to assume it
   complies to this document just because the first character is a "V".
   As written above, the full header MUST be validated to assume this.


   The Version field denotes the version of the syslog protcol
   specification the message is formatted to. It is used to uniquely
   identify the message format should later revisions of the syslog
   protocol specification change the format.

   Note well: this document is the first to specify this format,
   including the VERSION in the header. Any previous syslog
   specification had a different header. As outlined under HEADER above,
   an invalid HEADER will automatically tell the receiver that the
   message is NOT compliant to this specification. As such, all version
   information is well defined (absence of version information means
   legacy syslog by the fact that the header is invalid).

   The VERSION MUST be a numerical value. It MUST be one of the IANA
   assigned valid VERSION numbers. It starts at 1, which means the
   format specified in this document. The VERSION number MUST be
   incremented for each new syslog protocol specification that changes

Gerhards                Expires August 16, 2004                [Page 10]

Internet-Draft            The syslog Protocol              February 2004

   the format. If MUST NOT be incremented if a new syslog protocol
   specification does not change the syntax and semantics of the message

   The sender of the syslog message MUST specify the VERSION of the
   format that the message was formatted to.

   The receiver MUST check the VERSION. If the VERSION is within the set
   of format versions supported by the receiver, the receiver MUST parse
   the message according to the correct syslog protcol specification. A
   receiver MUST NOT parse a previous version with some parsing rules
   from a later specification.

   If the receiver does not support the specified VERSION, it SHOULD log
   a diagnostic message. It SHOULD NOT parse beyond the VERSION field.
   This is because the header format may have changed in a newer
   version. It SHOULD NOT try to process the message, but I MAY try this
   if the administrator has configured the receiver to do so. In the
   later case, the results may be undefined. If the administrator has
   instructed the receiver to parse non-supported version, it SHOULD
   assume that these messages are legacy syslog messages and parse and
   process them in respect to RFC 3164. Again, the administrator MAY
   configure the receiver to use a different algorithm.

   To be precise, a receiver receiving an unknown VERSION number, MUST,
   by default, ignore it. The administrator may configure it to not
   ignore it. Then, the receiver MUST, by default, parse it according to
   RFC 3164. The administrator may again override this setting. In this
   case, the receiver MAY use whatever method the administor has
   choosen. In this case, the receiver MUST ensure that no application
   reliability issue occurs. If there is a chance for this, it MUST NOT
   allow the administrator to select an insecure mode.

   The spirit of this behaviour is that the administrator may sometime
   need the power to allow overriding of version-specific parsing, but
   this should be done in the most secure and reliable way. Therefore,
   the receiver MUST use the appropriate defaults specified above. This
   document is so specific on the defaults and modes because it is
   common experience that parsing unknown formats often leads to
   security issues.

4.1.2 enterpriseID

   The enterprise ID unquily identifies the vender whom's software or
   device created the message. This is to support log-parsers
   sub-parsing vendor-specifc information from the message part.

   The enterprise ID is an integer. It MUST be the enterprise ID

Gerhards                Expires August 16, 2004                [Page 11]

Internet-Draft            The syslog Protocol              February 2004

   assigned by IANA to the vendor whoms software or device created the
   syslog message.


   The facility is primarily a way to filter messages at the receiver.
   It is a numerical value. There exist some traditional facility code
   semantics for the codes in the range from 0 to 23. These semantics
   are not closely followed by all vendors, softwares and devices.
   Therefore, no specifc semantics for facility codes are implied in
   this document.

   FACILITY is just a sender-supplied numerical identifier that can be
   used for filtering by the receiver. The facility in itself does not
   have any semantics. Semantics MUST be applied by site configuration
   (through the site's administrator).

   Any implementation of this document MUST support free configuration
   of the FACILITY on the sender.


   The SEVERITY field is used to indicate the severity that the sender
   of the message assgined to it. It is a numerical value with just few
   values. The traditional syslog severity values are reused, because
   they have prooven to be useful and sufficient in reality.

   SEVERITY is a numerical field, which MUST contain one of the digits
   from 0 to 7. Any other value is invalid and MUST NOT be used.

   Each of the numerical codes has been assigned the follwing semantics:

           Numerical         Severity

              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

   All implementations SHOULD try to assign the most appropriate
   severity to their message. Most importantly, test aid like messages
   or programm debugging information SHOULD be assiged severity 7.

Gerhards                Expires August 16, 2004                [Page 12]

Internet-Draft            The syslog Protocol              February 2004

   Severity 0 SHOULD be reserved for high-priviledge core processes of
   very high importance (like serious hardware failures or a very soon
   power failure). An implementation MAY use severities 0 and 7 for
   other purposes if this is configured by the administrator.

   In general, a receiver should abide to the fact that severities are
   often very subjective. As such, a receiver MUST not assume that all
   senders have the same sense of severities.


   The TIMESTAMP field is a formalized timestamp as taken from RFC 3339

   Note well: RFC 3339 makes allowances for multiple syntaxes for a
   timestamp to be used in various cases.  This document mandates a
   restricted set of syntaxes.  The primary characteristics of TIMESTAMP
   used in this document are as follows.

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

   o  usage of the "T" character is mandatory. It MUST NOT be replaced
      by any other character (like a SP character).

   o  the sender SHOULD include time-secfrac (fractional seconds) if its
      clock accuracy and performance permits.

   o  the entire length of the TIMESTAMP field MUST NOT exceed 32

   Please also note that RFC 3339 permits the value "60" in the second
   part to indicate a leap second. This must not be misinterpreted. As a
   suggestion for application developer, it is advised to replace the
   value "60" if seen in the header, with the value "59" if it otherwise
   can not be processed, e.g. stored to a database. It SHOULD NOT be
   converted to the first second of the next minute. Please note that
   such a conversion, if done on the message text itself, will cause
   cryptographical signatures to become invalid. As such, it is
   suggested that the adjustment is not done when the plain message text
   is to be stored (e.g. for later verification of signatures).

   Two samples of this format are:



   The first represents 20 minutes and 50.52 seconds after the 23rd hour

Gerhards                Expires August 16, 2004                [Page 13]

Internet-Draft            The syslog Protocol              February 2004

   of April 12th, 1985 in UTC.  The second represents the same time but
   expressed in the Eastern US timezone (daylight savings time being

   A single space character MUST follow the TIMESTAMP field. Syslog Senders without knowledge of Time

   There is one special case, and this is a syslog sender that is NOT
   aware of time at all. It can be argued if such a syslog sender is
   something that actually can be found in todays IT infrastructure.
   However, discussion has indicated that those things may exist in
   reality and as such there should be a guideline what to do in such a
   case. The other assumes that those syslog senders will most probably
   be found in embeded devices.

   Note well: an implementation MUST emit a valid TIMESTAMP if the
   underlying operating system, programming system and hardware is
   capable of doing so. A proper TIMESTAMP MUST be emited even if it is
   hard, but doable, to obtain the system time. The rule outlined here
   MUST only be used when there is absolutely no way to obtain time
   information from the system environment. This rule MUST NOT be used
   as an excuse for lazy implementations.

   A syslog sender who has absolutely no way of obtaining system time
   from its environment, MUST write the following TIMESTAMP:


   This TIMESTAMP is in the past, but more importantly, it shows a time
   that never existed, because January, 1st 2000 had no leap second
   (note the 60 in the second indicator). As such, this TIMESTAMP can
   never exist in a valid syslog message, but it is still syntactially
   correct in regard to the ABNF above.

   If a syslog receiver receives this TIMESTAMP it MUST treat the
   TIMESTAMP to be well-formed but MUST also know that the sender had no
   idea of what the time actually is. It is left to the application
   devloper what this means for further processing of the message (this
   is beyond the scope of this document).


   The HOSTNAME field contains the original creator of the syslog

   The HOSTNAME field SHOULD contain the host name and the domain name
   of the originator in the format specified in STD 13 [2]. This format

Gerhards                Expires August 16, 2004                [Page 14]

Internet-Draft            The syslog Protocol              February 2004

   will be referred to in this document as HOSTNAME-STD13.

   If the HOSTNAME-STD13 is not known to the orginator, it MUST use
   either its IPv4 address or its IPv6 address.

   If the IPv4 address is used, it MUST be shown as the dotted decimal
   notation as used in STD 13 [3], and will be referred to as
   HOSTNAME-IPV4.  If an IPv6 address is used, any valid textual
   representation used in RFC 2373 [8], section 2 MAY be used and will
   be referred to as HOSTNAME-IPV6.

   If a device has multiple IP addresses, it SHOULD use a consistent
   value in the HOSTNAME field. This consistent value MUST be one of its
   actual IP addresses. As an alternative, it MAY use the IP address of
   the interface that is used to send the message.

   A single space character MUST follow the HOSTNAME field.

4.1.7 TAG

   The TAG is a string of visible (printing) characters excluding SP,
   that MUST NOT exceed 64 characters in length. The first occurrence of
   a SP (space) will terminate the TAG field, but is not part of it.

   Note well: the colon (":") is NOT a special character inside the TAG.
   It may occur anywhere within it and may occur muliple times. The TAG
   is terminated by the first SP, NOT the colon character.

   The TAG is used to denote the sender of the message. It MUST be in
   the syntax shown in the ABNF above.

   A typical example of a TAG is: (without the quotes)


   Another example with a dynamic id may be:


   Another example (from VMS) is: (without the quotes)


   Please note that in this example,
   "DKA0:[MYDIR.SUBDIR1.SUBDIR2]MYFILE.TXT;1" is the static-id while
   "[123,456]" is still the full-dyn-id. This shows that a receiver must
   be prepared for special characters like '[' and ':' to be present
   inside the static part.

Gerhards                Expires August 16, 2004                [Page 15]

Internet-Draft            The syslog Protocol              February 2004

   As a note to implementors: the beginning of the full-dyn-id is not
   the first but the LAST occurrence of '[' inside the tag and this ONLY
   if the tag ends in either "]" or "]". If these conditions are not
   met, the '[' is part of the static-id.

   Systems that use both process-ID's and thead-IDs, SHOULD fill both
   the proc-id and the thread-part. For other systems it is RECOMMENDED
   to use the proc-id only.

   No specific format inside the tag is required. However, a sender
   SHOULD use a consistent tag value.

4.2 MSG

   The MSG part contains the details of the message. This has
   traditionally been a freeform message that gives some detailed
   information of the event. It MAY also contain structured data as
   described in Structured Data (Section 5) below.

   The code set used in MSG must be UNICODE. It MUST be encoded in UTF-8
   as specified in RFC 2279 [6]. A sender MAY issue any valid UTF-8
   sequence. A receiver MUST accept any valid UTF-8 sequence. Most
   importantly, it must not fail if control characters are present in
   the MSG part.

   Note to implementors: the octect value 0 (0x00), the C string
   terminator, is a valid character and MAY be present in the MSG part.
   The implementor must ensure that reception of 0x00 causes no
   malfunction, specifically does not cause message truncation. C
   programmers please be aware that this requires proper escaping and/or
   special string handling.

   Another note to implementors: please keep the presence of control
   characters in mind when writing textual log files. For example, LF is
   a valid character and may be present in the MSG part. Writing this
   plainly to a log file may cause problems with log parsers and other
   programs that process the log file. It is good practice to escape
   non-printable characters in a consistent way when writing to text

4.3 Examples

   The following examples are given.

   Example 1

         V1 0 888 4 2003-10-11T22:14:15.003Z mymachine.example.com su: 'su
         root' failed for lonvick on /dev/pts/8

Gerhards                Expires August 16, 2004                [Page 16]

Internet-Draft            The syslog Protocol              February 2004

   In this example, the VERSION is 1 (formatted according this
   document), the enterprise ID is 0 (IETF), the FACILITY has the value
   of 888 (whatever this means is up to the sender and recipient). The
   message was created The timestamp is in UTC. on October, 11th 2003 at
   10:14:15pm, 3 milliseconds into the next second. Please note that the
   sender had millisecond resolution. The sender may have actually had a
   better resolution, but by providing just three digits for the
   fractional settings, he does not tell us this. The message orignated
   from a host that calls itself "mymachine.example.com". The TAG is
   "su:". Note that the colon is part of the tag. The MSG is "'su root
   failed for lonvick...". Please note that the SP after the TAG is NOT
   part of the MSG - it is the seperator between TAG and MSG.

   As a note to implementors: please note that the sender had
   millisecond time resolution in this example. A common coding bug is
   that leading zeros are not written for fractional seconds. Very
   often, the above timestamp is errornously being written as:
   "2003-10-11T22:13:14.3". This would indicate 300 milliseconds instead
   of the 3 milliseconds that are actually meant. Please make sure that
   an implementation handles this correctly.

   Example 2

         V1 0 20 6 2003-08-24T05:14:15.000003-09:00
         myproc[10]:%% It's time to
         make the do-nuts. %%  Ingredients: Mix=OK, Jelly=OK #
         Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
         Conveyer1=OK, Conveyer2=OK # %%

   In this example, the VERSION is again 1 and the enterprise ID 0. The
   FACILITY is within the legacy syslog range (20), as such we assume
   the user has specifically configure the sender to use this FACILITY.
   The severity is 6 ("Notice" semantics). The timestamp now has
   microsecond resolution, indicated by the additional digits in the
   fractional seconds. The sender indicates that its local time is -9
   hours from UTC. Given the date stamp, we can assume the sender is in
   the US Pacific time zone during daylight savings time. The HOSTNAME
   is "", so the sender did not know its host- and domainname
   and used the V4 IP address instead. The TAG is "myproc[10]:%%" - we
   can speculate that the sender actually wanted the tag to be
   "myproc[10]:", but because there was no SP following it, the TAG
   continues until the first SP. The message is "It's time to make the

Gerhards                Expires August 16, 2004                [Page 17]

Internet-Draft            The syslog Protocol              February 2004

   Example 3 - An Invalid Message

         V1 0 20 6 2003-08-24T05:14:15.000000003-09:00
         myproc[10]:%% It's time to
         make the do-nuts. %%  Ingredients: Mix=OK, Jelly=OK #
         Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
         Conveyer1=OK, Conveyer2=OK # %%

   This example just just like Example 2, but this time the sender is
   overdoing with the clock resolution. It is supplying nanosecond
   resolution. This will result in the TIME-SECFRAC part to be longer
   than the allowed 6 digits, which invalidates the header and thus the
   message. A receiver MUST NOT try to "fix" this error. It MUST detect
   this as an invalid message and SHOULD log a diagnostic entry. If the
   receiver is capable of processing legacy syslog messages, it MUST
   assume that this message is legacy syslog and act accordingly.

Gerhards                Expires August 16, 2004                [Page 18]

Internet-Draft            The syslog Protocol              February 2004

5. Structured Data

   While syslog traditionally contains freeform data, there may be
   structured data present in the MSG part of a syslog message.
   Structured data are special, well defined data elements designed to
   be easily computer-parsable. They may transport meta data for the
   syslog protocol as well as application-defined information (like
   traffic counters, IP addresses and other well-defined elements).

   There is a certain set of structured data that is under IANA control.
   These structured data elements are described in this and other RFCs.
   A second set of structured data elements is not under IANA-control.
   This set MUST be used for experimental or vendor-specific elements.

   A syslog message may contain none, one or multiple structured data

5.1 Format

   Structured data can be present anywhere within the MSG part and
   follows this ABNF:

      ; Format of structured data element
      STRUCTURED-DATA = "[@#" SD-ID 0*(1*SP SD-PARAM) *SP "]"
      SD-ID           = SD-ID-IANA / SD-ID-EXPERI
      SD-ID-IANA      = 1*1ID-CHAR [1*1ID-CHARNOSLASH [1*62ID-CHAR]]
      SD-ID-EXPERI    = %d120 "-" 1*62ID-CHAR ; "x-" (lower case 'x'!)
      ID-CHAR         = %d32-33 / %d35-60 / %d62-92 / %d94-126 /
                        ; all US-ASCII but '"' (%d34), '=' (%d61), ']'
                        ; (%d93)
      ID-CHARNOSLASH  = %d32-33 / %d35-44 / %d46-60 / %d62-92 /
                        %d94-126 / %d128-254
                        ; same as ID-CHAR but without '-' (%d45)
      SD-PARAM        = PARAM-ID "=%d34" PARAM-VALUE "%d34"
      PARAM-ID        = 1*64ID-CHAR
      SAFE-CHAR       = *((%d32-33) / (%d35-46) / (%d48-92) /
                        (%d94-126) / (%d128-254))
      ESCAPED-CHAR    = ("\\" / %d47.34 / "]")  ; 47.34 is \"

   Each structured data element MUST begin with the token "[@#". This
   designates it as a special entity. This three-character sequence is
   highly likely not to be confused with traditional syslog message

   The beginning token MUST immediatly be followed by the ID of the
   structured data element. No space is allowed between the beginning

Gerhards                Expires August 16, 2004                [Page 19]

Internet-Draft            The syslog Protocol              February 2004

   token and the SD-ID. The SD-ID uniquely identifies the type and
   purpose of the element.

   IANA controls ALL SD-IDs without a hyphen '-' in the second character
   position. Experimental or vendor-specific SD-IDs MUST start with
   "x-". Values with a hypen on the second character position and the
   first character position not being a lower case "x" are undfined and
   SHOULD NOT be used. Receivers MAY accept them.

   If a receiver receives a well-formed but unknown SD-ID, the receiver
   SHOULD ignore this element. It MUST NOT malfunction because of this
   unknown SD-ID.

   The SD-ID is followed by none, one or many optional parameter/value
   pairs. Each of them MUST start with the parameter name, MUST be
   followed by an equal sign and quote sign. There MUST NOT be any space
   between the SD-ID, the equal and the quote sign. This is followed by
   the parameter value and then another quote sign.

   The parameter value may contain any character, but the three special
   characters '"', '\' and ']' MUST be escaped. This is neccessary to
   avoid parsing errors. Please note that escaping ']' would actually
   not be necessary but is required in order to avoid parser
   implementation errors. Each of these three characters MUST be escaped
   as '\"', '\\' and '\]' respectively. If a receiver receives an

   A backslash ('\') followed by none of the three described characters
   is considered an invalid escape sequence. Upon reception of such an
   invalid message, the receiver MUST replace the two-character sequence
   with just the second character received. It is recommended that the
   receivers logs a diagnostic message in this case. The receiver MUST
   otherwise ignore the invalid escape sequence.

   Parameter/Value pairs MUST be separated by at least one SP character.

   The structured data element MUST be terminated by the character ']',
   the ending token. This MUST follow the last parameter/value pair.
   There SHOULD be no SP in front of the ending token, but there MAY be
   one or multiple SP in front of it.

   If multiple structured data elements are written, it is RECOMMENDED
   that they are all sequentially written and no SP be written between
   those elements. However, they MAY occur at any position inside MSG.

   The order of structured data elements inside the MSG is irrelevant,
   except for IANA-assigned SD-IDs which specifically require a certain
   order. The same SD-ID MAY exist more than once inside a MSG if this

Gerhards                Expires August 16, 2004                [Page 20]

Internet-Draft            The syslog Protocol              February 2004

   is permitted by the SD-ID type.

5.2 MSG with just Structured Data

   Any syslog MSG may contain structured as well as traditional free
   form data. The free form (or unstructured) part of the syslog MSG is
   obtained by omiting all the structured data elements from the MSG.

   The resulting free from part of the MSG may consist purely of one or
   more SPs. This is considered as a MSG with just structured data

   As far as this specification goes, there is no implied special action
   to be taken on messages without a free form content in the MSG field.
   This case is just defined so that it may be used for
   implementation-specifc (and probably user-configurable) actions.

5.3 Examples

   All examples show the MSG part of the syslog message only. All
   examples should be considered to be on one line. They are wrapped on
   multiple lines for readabily purposes, only.

   Example 1

        [@#x-adiscon-iut iut="3" EventSource="Application"
        EventID="1011"]This is event 1011

   This example is a MSG with an experimental SD-ID of type
   "x-adiscon-iut" which has two parameters. This is followed by the
   free form text "This is event 1011".

   Example 2

        [@#x-adiscon-iut iut="3" EventSource="Application"
        EventID="1011"]This is event 1011 [@#x-adiscon-priority

   This is the same example, but with a second structured data element.
   Please note that the structured data element does not immediately
   follow the first one. Also note that the free form message is
   different from the example 1. It now is "This is event 1011>SP<" -
   notice the extra space character at the end.

   Example 3

        This is event[@#x-adiscon-priority class="high"] 1
        [@#x-adiscon-iut iut="3" EventSource="Application

Gerhards                Expires August 16, 2004                [Page 21]

Internet-Draft            The syslog Protocol              February 2004


   In this example, <SP> is actually a single space character. Although
   all elements are re-odered and the free form message is intermixed
   with structured data, it is still exactly the same message as in
   example 2. The message formatting shown in example three SHOULD be
   avoided by syslog senders. However, receivers MUST accept messages
   formatted in that way.

   Example 4

        [ @#x-adiscon-iut iut="3" EventSource="Application"
        EventID="1011"]This is event 1011

   Example four looks very much like example one. However, it is totally
   different because example four does NOT contain any structured data
   element at all. This is because there is a SP between the bracket and
   the rest of the beginning token "@#". As such, the three-character
   beginning token is not identifiable and not parsed as such. Receivers
   receiving this format MUST NOT assume structured data. This is
   especially important as legacy syslog data may very well contain a
   sequence as shown above which actually is no structured data.

   Example 5

        [@#sigSig Ver="1" RSID="1234" ... Signature="......"]

   Example 5 is not a full example. It shows how a hypothetical IANA
   assigned SD-ID may be used inside an otherwise empty message. Please
   note that the dots denote missing fields, which have been left out
   for brevity.

Gerhards                Expires August 16, 2004                [Page 22]

Internet-Draft            The syslog Protocol              February 2004

6. Multi-Part Messages

   Multi-part messages are an optional feature. It may be used if the
   amount of syslog data to be transmitted is larger than the maximum
   allowed for a single message. Multi-part messages are implemented
   using STRUCTURED-DATA elements.

6.1 Definitions

6.1.1 Original Message

   Multi-part syslog messaging is described in few terms. First, we have
   the "original message". This is the message that the original sender
   intended to send. It typically is larger than the syslog-allowed
   maximum message size.

6.1.2 Message Part

   To allow splitting the original message into multiple parts, the
   original message is split into one or many "message parts". Each
   "message part" is a part of the original message's message text. If
   all message parts are concatenated together, the result is the exact
   same original message.

6.1.3 Message Disassembly and Reassembly

   The process of concatenating the individual message parts is called
   "message reassembly". The process of spliting the orginal message
   into multiple message parts is called "message disassembly".

6.1.4 Multi-Part Message Header

   Message parts are no well-formed syslog messages in themself. They do
   not contain the required message header and they also do not contain
   the structured data elements necessary to support multi-part
   messaging. These things are called the "multi-part message header".

6.1.5 Message Part Message

   To transmit each message part, the multi-part message header MUST be
   added by the sender. When it is added, a complete syslog message is
   formed. his message is called the "message part message".

   During message reassembly, the multi-part message header MUST be
   removed to form the original message.

   A message part message is a syslog message in its own right. As such,
   it itself can be digitally signed. If so, the signature validates

Gerhards                Expires August 16, 2004                [Page 23]

Internet-Draft            The syslog Protocol              February 2004

   only the authenticy of the message part message but not necessarily
   that of the original message.

6.1.6 Multi-Part Messaging

   This whole process described here is called "multi-part messaging".

   If multi-part messages are used, special processing needs to take
   place. In order to avoid complexity, the receiver MUST reassemble the
   orginal message before parsing the message content. This original
   message MUST NOT contain the multi-part message structured data

   It is RECOMMENDED that multi-part messages are only used if the full
   message does not fit into a single syslog message. If the message
   fits, the multi-part messages feature SHOULD NOT be used. However, a
   sender may still choose to use it even in this case. Thus, a receiver
   MUST accept a multi-part message consisting of just a single message
   part message.

6.2 SD-ID msgpart

   Multi-part messaging uses the IANA-reserved "msgpart" SD-ID.

   The "msgpart" SD-ID is a structured data element with 3 parameters.
   It describes a single part of a multi-part message. It MUST begin
   immediately after the HEADER of the syslog message. The fragment of
   the original message immediatly begins AFTER the closing token (']')
   of the msgpart SD-ID. There MUST NOT be any SP or other character
   between the closing token and the begin of the actual message

   The receiver of a message part message MUST NOT try to parse
   structured data elements inside a single message part. This MUST only
   be done on the fully re-assembled message. The reason for this is
   that a single message part may be missing important tokens that will
   lead to misdetection of structured data elements.

   The "fragement" SD-ID has three parameters: msgid, partnum,
   partcount. Each of them is described in detail in the following

   All message part messages of a single syslog message MUST have the
   exact same syslog message header, most importantly the exact same
   timestamp. It is RECOMMENDED that a sender implementing multi-part
   messaging provides better-than-second time-resolution inside the

Gerhards                Expires August 16, 2004                [Page 24]

Internet-Draft            The syslog Protocol              February 2004

6.2.1 msgid

   The parameter "msgid" is an integer value in the range 0..2147483648.
   It MUST uniquely identify a message for a given TIMESTAMP. It SHOULD
   at least uniquely identify a message between two reboots of the
   syslog sender.

   It is RECOMMENDED that an incrementing value is used, which MAY be
   reset to 0 at the time of the syslog sender's startup. If the value
   is incremented and the maximum value is reached, than it is
   RECOMMENDED to reset the msgid to 0.

   Two otherwise identical msgid received in different message part
   messages with different TIMESTAMP in the header MUST be considered to
   be two different msgid.

6.2.2 partnum

   The parameter "partnum" is an integer value in the range
   1..2147483648. This value MUST start at one for the first message
   part message and MUST be incremented by one for each subsequent
   message part message.

   The "partnum" counter MUST be processed on a per-message basis. That
   is, when the next full syslog message is to be sent as a multi-part
   message, its first message part message again starts with "partnum"
   set to 1.

   The "partnum" counter MUST never be greater than "partcount". If it
   ever is greater, all message part messages MUST be considered
   invalid. It is RECOMMENDED that a diagnostic message is logged in
   that case.

   If the "partnum" is outside the defined range, all message part
   messages MUST be considered invalid. It is RECOMMENDED that a
   diagnostic message is logged in that case.

6.2.3 partcount

   The parameter "partcount" is an integer value in the range
   1..2147483648. It specifies into how many message part messages the
   message has been split into.

   The "partcount" parameter MUST either remain the same for all message
   part messages or it must be increasing. If it is increasing,
   "partcount" MUST be higher for all message part messages which have a
   higer "partnum" than the message in question. If an implementor
   decides to use an increasing "partcont", it MUST NOT be incremented

Gerhards                Expires August 16, 2004                [Page 25]

Internet-Draft            The syslog Protocol              February 2004

   (each one being one higher than the previous one). An implementation
   MAY increase the "partcount" by any value, as long as the next
   message part message has a higher "partcount" than the previous one.
   A receiver MUST NOT assume that "partcount" is being incremented. If
   a receiver receives a message part message with a lower "partcount"
   but a higher "partnum" than any previously received message part
   message for this multi-part message, all message part messages MUST
   be considered invalid. It is RECOMMENDED that a diagnostic message is
   logged in that case.

   Note well: A receiver can not assume reliable, in-order delivery of
   messages. An exception is if the underlying transport mapping
   explicitly gurantees this. The minimum required transport mapping
   outlined in Section 3.1 does NOT guarantee this. As such, the
   receiver must ensure that the above rules are obyed even when message
   part messages are received out of order. This is a situation where
   message part messages with a higher partnum and partcount are
   received before message part messages with lower partnum and
   partcount. This in itself is no violation of the rules stated above
   and MUST NOT be detected as malformed just for this reason (of
   course, it could be malformed for other reasons).

   If the "partcount" is outside the defined range, all message part
   messages MUST be considered invalid. It is RECOMMENDED that a
   diagnostic message is logged in that case.

6.3 Cryptographically Signing Multi-Part Messages

   While the author of this draft does not intend to specify how
   messages can be signed, he would like to offer a suggestion on the
   implications of multi-part messages.

   Multi-part messages need to be transmitted in indvidual parts and
   need to be reassmebled to be processed, at least in many cases.
   During reassembly, the multi-part message header is stripped from the
   message. This poses a problem to cryptographically signing the

   An obvious solution to keeping the message signature intact is that
   only the original, full-size message is signed. Then, the individual
   message part messages are transmitted without a specifc signature
   attached to them. Only the re-assembled message will then be used for
   verifying the signature.

   This mode will probably be very efficient, as the ultimate goal is to
   guarantee the integrity of the original message. Any modification to
   the message part messges will either result in a protocol error or a
   modification of the signed original message. Both of this will be

Gerhards                Expires August 16, 2004                [Page 26]

Internet-Draft            The syslog Protocol              February 2004

   detected by verifying the signature in the original, reassembled,

   One problem, however, may be caused to signature verifiers who work
   on raw logs. Raw logs will most probably include only the individual
   message part messages. If this is an issue, it may be worth thinking
   about signing both the original message as well as each individual
   message part messages. So the message would effectively be signed
   twice and verifiable in each state.

   The author of this draft thinks it is NOT advisable to only sign the
   individual message part message. While this would guarantee the
   authenticy of the individual fragments, no authentic signature could
   be provided for the reassembled message. This may cause serious
   issues with higher-level signature verifiers.

   Again, these are just thoughts about implementing signatures.
   Depending on the signature specification used, there may be different
   solutions. It is RECOMMENDED that authors of signing specifications
   specifically describe how their specification deals with multi-part
   messages. Authors of signing specifications MUST NOT prohibit the use
   of multi-part messages.

6.4 Multi-Part Message Examples

   To conserve some space, we use an abbreviated sample, where not all
   data is shown:

   Base Example

        <34>2004-01-19T22:14:15.002 mymachine mwagent:
        [@#x-adiscon-iut iut="3" EventSource="Application"
           (some lenghty params) EventID="1011"][@#x-adiscon-priority
        class="high"]This is event 1011.
        (lengthy data) This is the end.

   We assume that the lengthy data is longer than does fit into a single
   syslog message. As such, it needs to be transmitted as multi-part
   message. To keep it simple, we assume that "(some lengthy paramters)"
   and "(lenghty data)" are the lengthy parts and that their length
   forces us to create three message part messages.

   The initial message part message will just contain structured data,
   the second message part message some structured data and some free
   form data and the last message part message only free form data. This
   is how they look:

Gerhards                Expires August 16, 2004                [Page 27]

Internet-Draft            The syslog Protocol              February 2004

   Example Message Part Message One

        <34>2004-01-19T22:14:15.002 mymachine mwagent:
        [@#fragment msgid="12" partcount="3" partnum="1"]
        [@#x-adiscon-iut iut="3" EventSource="Application"
           (some lenghty params) EventID="1011"][@#x-adiscon-prior

   Example Message Part Message Two

        <34>2004-01-19T22:14:15.002 mymachine mwagent:
        [@#fragment msgid="12" partnum="2" partcount="3"]
        ity class="high"]This is event 1011.  (lengthy
        data) This i

   Example Message Part Message Three

        <34>2004-01-19T22:14:15.002 mymachine mwagent:
        [@#fragment msgid="12" partnum="3"
        partcount="3"]s the end.

   There are some things worth noting when looking at the examples:

   o  The header, and most importantly the TIMESTAMP is the same for all
      three messages, even though message part messages two and three
      are most probably send at a slightly later time. Please also note
      that a TIMESTAMP is used to facilitate msgid uniquenes.

   o  The value for "msgid", 12, is just taken randomly for this

   o  The sequence of "partnum" and "partcount" is not fixed - their
      order is different in message part message one than in message
      part message two and three. This is irrelevant.

   o  The "x-adiscon-priority" SD-ID is split between message part
      messages one and two. This is the reason why parsing structured
      data should only be done on the re-assmbled (original) message.
      Parsing the message part messages themselfs may seriously confuse
      the parser.

   o  Note how the freeform message part is split between message part
      message two and three. In message part message three, it starts
      with "]s" to complete the "its" from the original message. Please
      note that if in message part message three it had been "] s", this
      would have been reassembled to be "it s" (with a SP in between).

Gerhards                Expires August 16, 2004                [Page 28]

Internet-Draft            The syslog Protocol              February 2004

7. Structured Data IDs

   This section defines the currently IANA-registred structured data IDs
   (SD-IDs). See Section 5 for a definition of structured data elements.

7.1 msgpart

   This SD-ID is currently described in Section 6.2.

7.2 time

   The SD-ID "time" is used by the original sender to describe its
   notation of system time. This SD-ID SHOULD be written if the sender
   is not properly synchronized with a reliable external time source or
   if it does not know if its time zone information is correct. It MAY
   be written in any other case. The main use of this structured data
   element is to provide some information on how much the TIMESTAMP
   described in Section 4.1.5 can be trusted.

7.2.1 tzknown

   The "tzknown" parameter indicates if the original sender knows its
   timezone, as specified in the TIMESTAMP. If so, the value "1" MUST be
   used. If the time zone information is in doubt, the value "0" MUST be
   used. Please note that if the sender KNOWS its timezone but decides
   to emit UTC, the value "1" should still be used (because the time
   zone is known).

   It is suggested that an implementation uses "0" be default and
   changes to "1" only 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 explictely
   acknowledges the correctness of the time zone information.

   If a system is properly synchronized to an external time zone, the
   value "1" should be used in most cases. However, we known of external
   time zone synchronizations that do NOT provide the exact time zone
   information, just a precise local time. In such (rare) cases, the
   "time" structured data element should indicated a properly synced
   time but the absence of time zone information by setting the
   "tzknown" value to "0".

7.2.2 issynced

   The "issynced" parameter indicates if the original sender is
   synchronized to a reliable external time source, e.g. via NTP. If so,
   the value "1" MUST be provided. If not, the value "0" MUST be

Gerhards                Expires August 16, 2004                [Page 29]

Internet-Draft            The syslog Protocol              February 2004


7.2.3 syncaccuracy

   The "syncaccuracy" parameter indicates how accurate the original
   sender thinks the time synchronization it participates is.

   If the value "0" is used for "issynced", this parameter MUST NOT be
   written. If the value "1" is used for "issynced" but the
   "syncaccuracy" parameter is absent, a receiver should assume that the
   time information provided is accurate enough to be considered
   correct. The "syncaccuracy" parameter should ONLY be written if the
   original sender actually has knowledge of the reliabilty of the
   external time source. In reality, in most cases, it does not have
   this - then the "syncaccuracy" parameter MUST not be written to
   prevent false impressions.

   The "syncaccuracy" parameter is an interger describing the maximum
   number of milliseconds that the clock may be off between
   synchoronization intervals.

7.2.4 Example

   The following is an example of a system that knows that it does
   neither know its time zone nor is being synchronized:

   [@#time tzknown="0" issynced="0"]

   With this information, the sender indicates that its time information
   can not be trusted. This may be a hint for the receiver to use its
   local time instead of the message-provided TIMESTAMP for correlation
   of multiple messages from different senders.

   The following is an example of a system that has knows its time zone
   and knows that it is properly syncrhonized to an external source:

   [@#time tzknown="1" issynced="1"]

   The author considers this to be the typical case. While we do not
   know the accuracy of the external time synchronization, the time
   stamp should be good enough for all message correlations with other
   senders' messages.

   Note well: this case SHOULD be assumed by a receiver if not "time"
   structured data element is provided by the sender.

   The following is an example of a system that knows both its time zone
   and is externally synchronized. It also knows the accuracy of the

Gerhards                Expires August 16, 2004                [Page 30]

Internet-Draft            The syslog Protocol              February 2004

   external synchronization:

   [@#time tzknown="1" issynced="1" syncaccuracy="60000"]

   The difference between this and the previous example is that the
   device knows that its clock will be kept within 60 seconds (more or
   less) of the official time. So if the device reports it is 9:00:00,
   it is no earlier than 8:59:00 and no later then 9:01:00.

   Knowing the accuracy of the time synchronization can be helpful when
   correlating syslog messages.

   It is important to not create a false impression of accuracy. A
   sender MUST only indicate a given accuracy, if it actually knows it
   is within these bounds. It is generally assumed that the sender gains
   this in-depth knowledge through operator configuration. As such, by
   default, an accuracy should not be provided.

7.3 origin

   The SD-ID "origin" is optional. It MAY be used by a sender to
   indicate the origin of a syslog message. It has the following

7.3.1 format

   The "format" parameter is optional. If it is present, it denots the
   format that this message was originally been created in. Its value
   MUST be the number of the RFC it complies to. If the message complies
   to an Internet-Draft format, it must specifiy the full internet draft
   name. For example, as of this writing, format may either hold the
   string "3164" (RFC 3164) or "draft-ietf-syslog-protocol-03.txt".

7.3.2 ip

   The "ip" parameter is optional. If it is present, it denotes the IP
   address that the sender knows it had at the time of sending this
   message. It must be either the textual representation of an IPv4
   address or the textual representation of an IPv6 address as outlined
   in Section 4.1.6. A host name or FQDN MUST NOT be used inside the
   "ip" parameter.

   If a device has multiple IP addresses, it MAY either use a single of
   its IP addresses in the "ip" parameter or it MAY include MULTIPLE
   "ip" parameters in a single "origin" structured data element.

Gerhards                Expires August 16, 2004                [Page 31]

Internet-Draft            The syslog Protocol              February 2004

7.3.3 Example

   The following is an example with multiple IP addresses:

   [@#origin format="draft-ietf-syslog-protocol-03.txt ip=""

   This example is wrapped for readability. With it, the sender
   indicates that it has formatted the message according to this draft
   and it two ip address, one being and the other one being

Gerhards                Expires August 16, 2004                [Page 32]

Internet-Draft            The syslog Protocol              February 2004

8. Relay Operations

8.1 No Message Modification Allowed

   A relay MUST NOT modify any well-formed message it receives. This is
   even the case if the original sender had no knowledge of its time
   zone as outlined in Section

8.2 RFC 3164 Messages

   A relay has potentially needs to send and receive RFC 3164 [10] type
   messages. As we assume that RFC 3164 will be in wide use for a long
   time period after this document has been released, we would like to
   provide some guidelines on how to interoperate with RFC 3164 based

   These guidelines MUST be implemented if an implementation provides a
   way to communicate with a RFC 3164 based implementation. However, if
   an implementation does NOT provide any means to communicate with a
   RFC 3164 based implementation, this section can be ignored (as it
   does not apply).

   It is the intention of this section to provide clear guidelines on
   how this document interoperates with RFC 3164. The rules try to
   retain as much information as possible. Most importantly, these rules
   ensure that a message compliant to this document can travel via a RFC
   3164 relay chain without any information loss IF the final recipient
   is an implementation of this document.

8.2.1 Reception of RFC 3164 Messages

8.2.2 Sending RFC 3164 Messages

8.3 Creation of Multi-Part Messages

   There is one special case in which a relay MAY decide to modify a
   message. If a realy receives a message and knows that the message is
   larger than the largest message size supported by the transport
   mapping where it is to be sent over, the relay SHUOLD use multi-part
   messaging as outlined in Section 6 and thus disassemble the message
   into multiple message part messages. Alternatively, it MAY drop that
   part of the message that does not fit into the transport mappings
   message sice. It MAY also decide to drop the message completely.

   In any case, the relay SHOULD log a diagnostic message indicating the
   message receive, the action taken and the reasoning for this.

Gerhards                Expires August 16, 2004                [Page 33]

Internet-Draft            The syslog Protocol              February 2004

9. Security Considerations

   This section is to be updated once the rest of the document has been
   confirmed. The current content is incomplete and potentially not in
   sync with the rest of the draft.

9.1 Diagnostic Logging

   This document, in multiple sections, recommends that an
   implementation writes a diagnostic message to indicate unusual
   situations or other things noteworthy. Diagnostic messages are a very
   useful tool in finding configuration issues as well as a system

   Unfortunately, diagnostic logging can cause issues by itself, for
   example if an attacker tries to create a denial of service condition
   by willingly sending malformed messages that will lead to the
   creation of diagnostic log entries. Due to sheer volume, the
   resulting diagnostic log entries may exhaust system ressources, e.g.
   processing power, I/O capability or simply storage space. For
   example, an attacker could flood a system with messages generating
   diagnostic log entries after he has compromised a system. If the log
   entries are stored, e.g. in a circular buffer, the flood of
   diagnostic log entries would eventually overwrite useful previous

   Besides this risk, diagnostic message, if they occur too frequently,
   can become meaningless to many administrators. Common practice is to
   turn off diagnostic logging if it turns out to be too verbose. This
   potentially removes the administrator of important diagnostic

   While this document recommends to write meaningful diagnostic logs,
   the author also recommends to allow an administrator to limit the
   amount of diagnostic logging. At least, an implemenation SHOULD
   differentiate between critical, informational and debuging diagnostic
   message. Critical messages should only be issued in real critical
   states, e.g. expected or happening malfunction of the application or
   parts of it. A strong indication of an ongoing attack can eventually
   alse be considered critical. As a guideline, there should be very few
   critical message. Informational message should indicate all
   conditions not fully correct, but still within the bounds of normal
   processing. A diagnostic message logging the fact that a malformed
   message has been received is a good example of this category. A debug
   diagnostic message should not be needed during normal operation, but
   merely as a tool for setting up or testing a system (which includes
   the process of an administrator configuring multiple syslog
   applications in a complex environment). An application may decide NOT

Gerhards                Expires August 16, 2004                [Page 34]

Internet-Draft            The syslog Protocol              February 2004

   to provide any debugging diagnostic messages.

   An administrator should be able to configure the level for which
   diagnostic messages will be written. Non-configured diagnostics
   should not be written but discarded. An implementor may create as
   many different levels of diagnostic messages as he see useful - the
   above recommendation is just based on real-world experience of what
   is considered useful. Please not that experience also shows that too
   many levels of diagnostics typically do no good, because the typical
   administrator may no longer be able to understand what each level

   Even with this categorization, a single diagnostic (or a set of them)
   may frequnetly be generated when a specific condition exists (or a
   system is being attacked). It will lead to the security issues
   outlined at the beginning of this section. To solve this, it is
   recommended that an implementation allows to set a limit of how many
   "same" diagnostic messages will be generated within a limited amount
   of time. E.g. an administrator should be able to say that only the
   first 50 identical messages are logged within a 30 minute interval.
   All subsequent identical messages will be discarded until the next
   time interval. While this causes some information loss, it is
   considered a good compromise between avoiding overruns and providing
   most in-depth diagnostic information. An implementation offering this
   feature should allow the administrator to configure the number of
   identical messages as well as the time interval to whatever the
   administrator thinks to be reasonable for his needs. It is up to the
   implementor of what the term "identical" means. Some may decide that
   only totally identical (in byte-to-byte comparison) messages are
   actually identical, some other may say that a message which is of
   identical type but with just some changed parameter (e.g. changed
   remote host address) is also considered identical. Both approaches
   have there advantages and disadvantages. Probably, it is best to
   leave this, too, configurable and allow the administrator to set the

   This document does NOT require nor enforce the outlined diagnostic
   message categorization or the duplicate supression feature. It just
   would like to show some real-world solutions, which may be helpful
   for implementors. A system MAY claim to be compliant to this document
   even if it does not implement anything of the above.

9.2 Packet Parameters

   The message length must not exceed the maximum value outlined in
   Section 4.  Various problems may result if a device sends out
   messages with a greater length. To avoid inconsistencies between
   different implementations, oversize packets SHOULD be dropped.

Gerhards                Expires August 16, 2004                [Page 35]

Internet-Draft            The syslog Protocol              February 2004

   Inconsitencies between different implementations have shown to be a
   major security issue in many cases. So there is good reasoning for
   this somewhat harsh recommendation.

   Similarly, the multi-part messaging feature may be misused to overrun
   a receiver or a log analyzer with a gigantic message. Any process
   reassembling multi-part messages MUST properly check against the
   maximum re-assembled message size it supports. Oversize data SHOULD
   be dropped.

9.3 Single Source to a Destination

   The syslog records are usually presented (placed in a file, displayed
   on the console, etc.) in the order in which they are received.  This
   is not always in accordance with the sequence in which they were
   generated.  As they are transmitted across an IP network, some out of
   order receipt should be expected.  This may lead to some confusion a
   messages may be received that would indicate that a process has
   stopped before it was started.  This may be somewhat rectified if the
   originating process had timestamped or numbered each of the messages
   before transmission.  In this, the sending device should utilize an
   authoritative time source.  It should be remembered, however, that
   not all devices are capable of receiving time updates, and not all
   devices can timestamp their messages.

9.4 Multiple Sources to a Destination

   In syslog, there is no concept of unified event numbering.  Single
   devices are free to include a sequence number within the CONTENT but
   that can hardly be coordinated between multiple devices.  In such
   cases, multiple devices may report that each one is sending message
   number one.  Again, this may be rectified somewhat if the sending
   devices utilize a timestamp from an authoritative source in their
   messages.  As has been noted, however, even messages from a single
   device to a single collector may be received out of order.  This
   situation is compounded when there are several devices configured to
   send their syslog messages to a single collector.  Messages from one
   device may be delayed so the collector receives messages from another
   device first even though the messages from the first device were
   generated before the messages from the second.  If there is no
   timestamp or coordinated sequence number, then the messages may be
   presented in the order in which they were received which may give an
   inaccurate view of the sequence of actual events.

9.5 Multiple Sources to Multiple Destinations

   The plethora of configuration options available to the network
   administrators may further skew the perception of the order of

Gerhards                Expires August 16, 2004                [Page 36]

Internet-Draft            The syslog Protocol              February 2004

   events.  It is possible to configure a group of devices to send the
   status messages -or other informative messages- to one collector,
   while sending messages of relatively higher importance to another
   collector.  Additionally, the messages may be sent to different files
   on the same collector.  If the messages do not contain timestamps
   from the source, it may be difficult to order the messages if they
   are kept in different places.  An administrator may not be able to
   determine if a record in one file occurred before or after a record
   in a different file.  This may be somewhat alleviated by placing
   marking messages with a timestamp into all destination files.  If
   these have coordinated timestamps, then there will be some indication
   of the time of receipt of the individual messages.

9.6 Replaying

   This needs also to be addressed in each transport mapping. Here is
   the general information on the issue, the transport mapping should
   address the specifcs for the transport in question.

   Without any sequence indication or timestamp, messages may be
   recorded and replayed at a later time.  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 collector.  Even with a 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.

9.7 Reliable Delivery

   This could also be a place to elaborate about the SIMPLEX nature.

   As there is no mechanism within either the syslog process or the
   protocol to ensure delivery, and since the underlying transport is
   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 the drop of one or more syslog
   messages cannot be determined.  If the messages are simple status
   updates, then their non-receipt may either not be noticed, or it 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.

   RFC 3195 may be used for the reliable delivery of all syslog

Gerhards                Expires August 16, 2004                [Page 37]

Internet-Draft            The syslog Protocol              February 2004


9.8 Message Integrity

   Besides being discarded, syslog messages may be damaged in transit,
   or an attacker may maliciously modify them.  In the case of a packet
   containing a syslog message being damaged, there are various
   mechanisms built into the link layer as well as into the IP [9] and
   UDP protocols which may detect the damage.  An intermediary router
   may discard a damaged IP packet [10].  Damage to a UDP packet may be
   detected by the receiving UDP module, which may silently discard it.
   In any case, the original contents of the message will not be
   delivered to the collector.  Additionally, if an attacker is
   positioned between the sender and collector of syslog messages, they
   may be able to intercept and modify those messages while in-transit
   to hide unauthorized activities.

9.9 Message Observation

   While there are no strict guidelines pertaining to the event message
   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.  Neither the syslog protocol
   nor the syslog application have mechanisms to provide confidentiality
   of the messages in transit.  In most cases passing clear-text
   messages is a benefit to the operations staff if they are sniffing
   the packets off of 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.

9.10 Misconfiguration

   Since 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 recipient.  Cases have been noted where devices were
   inadvertently configured to send syslog messages to the wrong
   receiver.  In many cases, the inadvertent receiver may not be
   configured to receive syslog messages and it will probably discard
   them.  In certain other cases, the receipt of syslog messages has
   been known to cause problems for the unintended recipient [13].  If
   messages are not going to the intended recipient, then they cannot be
   reviewed or processed.

Gerhards                Expires August 16, 2004                [Page 38]

Internet-Draft            The syslog Protocol              February 2004

9.11 Forwarding Loop

   As it is shown in Figure 1, 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 Priority
   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 to not cause such a death spiral.

9.12 Load Considerations

   Network administrators must take the time to estimate the appropriate
   size of the syslog receivers.  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 that has the consequence of not ensuring that an administrator
   will be able to review the records in the future. Along this line, a
   receiver or collector must have a network interface capable of
   receiving all messages sent to it.

   Administrators and network planners must also critically review the
   network paths between the devices, the relays, and the collectors.
   Generated syslog messages should not overwhelm any of the network

9.13 Denial of Service

   As with any system, an attacker may just overwhelm a receiver by
   sending more messages to it than can be handled by the infrastructure
   or the device itself. Implementors should attempt to provide features
   that minimize this threat. Such as only receiving syslog messages
   from known IP addresses.

9.14 Covert Channels

   Nothing in this protocol attempts to eliminate covert channels.
   Indeed, the unformatted message syntax in the packets could be very
   amenable to sending embedded secret messages.  In fact, just about
   every aspect of syslog messages lends itself to the conveyance of
   covert signals.  For example, a collusionist could send odd and even
   PRI values to indicate Morse Code dashes and dots.

Gerhards                Expires August 16, 2004                [Page 39]

Internet-Draft            The syslog Protocol              February 2004

10. IANA Considerations

   This document also upholds the Facilities and Severities listed in
   RFC 3164 [10].  Those values range from 0 to 191.  This document also
   instructs the IANA to reserve all other possible values of the
   Severities and Facilities above the value of 191 and to distribute
   them via the consensus process as defined in RFC 2434 [9].

   IANA must also maintain a registry of SD-ID values.

Gerhards                Expires August 16, 2004                [Page 40]

Internet-Draft            The syslog Protocol              February 2004

11. Authors and Working Group Chair

   The working group can be contacted via the mailing list:


   The current Chair of the Working Group may be contacted at:

         Chris Lonvick
         Cisco Systems
         Email: clonvick@cisco.com

   The author of this draft is:

         Rainer Gerhards
         Email: rgerhards@hq.adiscon.com

         Phone: +49-9349-92880
         Fax: +49-9349-928820

         Adiscon GmbH
         Mozartstrasse 21
         97950 Grossrinderfeld

Gerhards                Expires August 16, 2004                [Page 41]

Internet-Draft            The syslog Protocol              February 2004

12. Acknowledgements

   The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross,
   Albert Mietus, Anton Okmianski, Tina Bird, David Harrington and all
   other people who commented on various versions of this proposal.

Gerhards                Expires August 16, 2004                [Page 42]

Internet-Draft            The syslog Protocol              February 2004


   [1]   American National Standards Institute, "USA Code for
         Information Interchange", ANSI X3.4, 1968.

   [2]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [3]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [4]   Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.

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

   [6]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [8]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

   [9]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October

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

   [11]  Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

Author's Address

   Rainer Gerhards
   Adiscon GmbH
   Mozartstrasse 21
   Grossrinderfeld, BW  97950

   EMail: rgerhards@hq.adiscon.com

Gerhards                Expires August 16, 2004                [Page 43]

Internet-Draft            The syslog Protocol              February 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Gerhards                Expires August 16, 2004                [Page 44]

Internet-Draft            The syslog Protocol              February 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Gerhards                Expires August 16, 2004                [Page 45]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/