doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc3164.txt b/doc/rfc/rfc3164.txt
new file mode 100644
index 0000000..d0b0396
--- /dev/null
+++ b/doc/rfc/rfc3164.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                         C. Lonvick
+Request for Comments: 3164                                 Cisco Systems
+Category: Informational                                      August 2001
+
+
+                        The BSD syslog Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes the observed behavior of the syslog protocol.
+   This protocol has been used for the transmission of event
+   notification messages across networks for many years.  While this
+   protocol was originally developed on the University of California
+   Berkeley Software Distribution (BSD) TCP/IP system implementations,
+   its value to operations and management has led it to be ported to
+   many other operating systems as well as being embedded into many
+   other networked devices.
+
+Table of Contents
+
+   1. Introduction....................................................2
+   1.1 Events and Generated Messages..................................3
+   1.2 Operations of the Message Receivers............................5
+   2. Transport Layer Protocol........................................5
+   3. Definitions and Architecture....................................5
+   4. Packet Format and Contents......................................7
+   4.1 syslog Message Parts...........................................8
+   4.1.1 PRI Part.....................................................8
+   4.1.2 HEADER Part of a syslog Packet..............................10
+   4.1.3 MSG Part of a syslog Packet.................................11
+   4.2 Original syslog Packets Generated by a Device.................12
+   4.3 Relayed syslog Packets........................................12
+   4.3.1 Valid PRI and TIMESTAMP.....................................13
+   4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
+   4.3.3 No PRI or Unidentifiable PRI................................14
+   5. Conventions....................................................14
+   5.1 Dates and Times...............................................15
+   5.2 Domain Name and Address.......................................15
+
+
+
+Lonvick                      Informational                      [Page 1]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   5.3 Originating Process Information...............................15
+   5.4 Examples......................................................16
+   6. Security Considerations........................................18
+   6.1 Packet Parameters.............................................19
+   6.2 Message Authenticity..........................................19
+   6.2.1 Authentication Problems.....................................19
+   6.2.2 Message Forgery.............................................20
+   6.3 Sequenced Delivery............................................20
+   6.3.1 Single Source to a Destination..............................20
+   6.3.2 Multiple Sources to a Destination...........................21
+   6.3.3 Multiple Sources to Multiple Destinations...................21
+   6.3.4 Replaying...................................................22
+   6.4 Reliable Delivery.............................................22
+   6.5 Message Integrity.............................................22
+   6.6 Message Observation...........................................22
+   6.7 Message Prioritization and Differentiation....................23
+   6.8 Misconfiguration..............................................24
+   6.9 Forwarding Loop...............................................24
+   6.10 Load Considerations..........................................25
+   7. IANA Considerations............................................25
+   8. Conclusion and Other Efforts...................................25
+   Acknowledgements..................................................26
+   References........................................................27
+   Author's Address..................................................28
+   Full Copyright Statement..........................................29
+
+1. Introduction
+
+   Since the beginning, life has relied upon the transmission of
+   messages.  For the self-aware organic unit, these messages can relay
+   many different things.  The messages may signal danger, the presence
+   of food or the other necessities of life, and many other things.  In
+   many cases, these messages are informative to other units and require
+   no acknowledgement.  As people interacted and created processes, this
+   same principle was applied to societal communications.  As an
+   example, severe weather warnings may be delivered through any number
+   of channels - a siren blowing, warnings delivered over television and
+   radio stations, and even through the use of flags on ships.  The
+   expectation is that people hearing or seeing these warnings would
+   realize their significance and take appropriate action.  In most
+   cases, no responding acknowledgement of receipt of the warning is
+   required or even desired.  Along these same lines, operating systems,
+   processes and applications were written to send messages of their own
+   status, or messages to indicate that certain events had occurred.
+   These event messages generally had local significance to the machine
+   operators.  As the operating systems, processes and applications grew
+   ever more complex, systems were devised to categorize and log these
+   diverse messages and allow the operations staff to more quickly
+
+
+
+Lonvick                      Informational                      [Page 2]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   differentiate the notifications of problems from simple status
+   messages.  The syslog process was one such system that has been
+   widely accepted in many operating systems.  Flexibility was designed
+   into this process so the operations staff have the ability to
+   configure the destination of messages sent from the processes running
+   on the device.  In one dimension, the events that were received by
+   the syslog process could be logged to different files and also
+   displayed on the console of the device.  In another dimension, the
+   syslog process could be configured to forward the messages across a
+   network to the syslog process on another machine. The syslog process
+   had to be built network-aware for some modicum of scalability since
+   it was known that the operators of multiple systems would not have
+   the time to access each system to review the messages logged there.
+   The syslog process running on the remote devices could therefore be
+   configured to either add the message to a file, or to subsequently
+   forward it to another machine.
+
+   In its most simplistic terms, the syslog protocol provides a
+   transport to allow a machine to send event notification messages
+   across IP networks to event message collectors - also known as syslog
+   servers.  Since each process, application and operating system was
+   written somewhat independently, there is little uniformity to the
+   content of syslog messages.  For this reason, no assumption is made
+   upon the formatting or contents of the messages.  The protocol is
+   simply designed to transport these event messages.  In all cases,
+   there is one device that originates the message.  The syslog process
+   on that machine may send the message to a collector.  No
+   acknowledgement of the receipt is made.
+
+   One of the fundamental tenets of the syslog protocol and process is
+   its simplicity.  No stringent coordination is required between the
+   transmitters and the receivers.  Indeed, the transmission of syslog
+   messages may be started on a device without a receiver being
+   configured, or even actually physically present.  Conversely, many
+   devices will most likely be able to receive messages without explicit
+   configuration or definitions.  This simplicity has greatly aided the
+   acceptance and deployment of syslog.
+
+1.1 Events and Generated Messages
+
+   The writers of the operating systems, processes and applications have
+   had total control over the circumstances that would generate any
+   message.  In some cases, messages are generated to give status. These
+   can be either at a certain period of time, or at some other interval
+   such as the invocation or exit of a program.  In other cases, the
+   messages may be generated due to a set of conditions being met.  In
+   those cases, either a status message or a message containing an alarm
+   of some type may be generated.  It was considered that the writers of
+
+
+
+Lonvick                      Informational                      [Page 3]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   the operating systems, processes and applications would quantify
+   their messages into one of several broad categories.  These broad
+   categories generally consist of the facility that generated them,
+   along with an indication of the severity of the message.  This was so
+   that the operations staff could selectively filter the messages and
+   be presented with the more important and time sensitive notifications
+   quickly, while also having the ability to place status or informative
+   messages in a file for later perusal.   Other options for displaying
+   or storing messages have been seen to exist as well.
+
+   Devices MUST be configured with rules for displaying and/or
+   forwarding the event messages.  The rules that have been seen are
+   generally very flexible.  An administrator may want to have all
+   messages stored locally as well as to have all messages of a high
+   severity forwarded to another device.  They may find it appropriate
+   to also have messages from a particular facility sent to some or all
+   of the users of the device and displayed on the system console.
+   However the administrator decides to configure the disposition of the
+   event messages, the process of having them sent to a syslog collector
+   generally consists of deciding which facility messages and which
+   severity levels will be forwarded, and then defining the remote
+   receiver.  For example, an administrator may want all messages that
+   are generated by the mail facility to be forwarded to one particular
+   event message collector.  Then the administrator may want to have all
+   kernel generated messages sent to a different syslog receiver while,
+   at the same time, having the critically severe messages from the
+   kernel also sent to a third receiver.  It may also be appropriate to
+   have those messages displayed on the system console as well as being
+   mailed to some appropriate people, while at the same time, being sent
+   to a file on the local disk of the device.  Conversely, it may be
+   appropriate to have messages from a locally defined process only
+   displayed on the console but not saved or forwarded from the device.
+   In any event, the rules for this will have to be generated on the
+   device.  Since the administrators will then know which types of
+   messages will be received on the collectors, they should then make
+   appropriate rules on those syslog servers as well.
+
+   The contents of a message have also been at the discretion of its
+   creator.  It has been considered to be good form to write the
+   messages so that they are informative to the person who may be
+   reading them.  It has also been considered good practice to include a
+   timestamp and some indication of the sending device and the process
+   that originated it in the messages.  However, none of those are
+   stringently required.
+
+   It should be assumed that any process on any device might generate an
+   event message.  This may include processes on machines that do not
+   have any local storage - e.g., printers, routers, hubs, switches, and
+
+
+
+Lonvick                      Informational                      [Page 4]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   diskless workstations.  In that case, it may be imperative that event
+   messages are transported to a collector so that they may be recorded
+   and hopefully viewed by an operator.
+
+1.2 Operations of the Message Receivers
+
+   It is beyond the scope of this document to specify how event messages
+   should be processed when they are received.  Like the operations
+   described in Section 1.1, they generally may be displayed to the
+   appropriate people, saved onto disk, further forwarded, or any
+   combination of these.  The rules for determining the disposition of
+   received messages have been seen to be identical to the rules for
+   determining the disposition of locally generated messages.
+
+   As a very general rule, there are usually many devices sending
+   messages to relatively fewer collectors.  This fan-in process allows
+   an administrator to aggregate messages into relatively few
+   repositories.
+
+2. Transport Layer Protocol
+
+   syslog uses the user datagram protocol (UDP) [1] as its underlying
+   transport layer mechanism.  The UDP port that has been assigned to
+   syslog is 514.  It is RECOMMENDED that the source port also be 514 to
+   indicate that the message is from the syslog process of the sender,
+   but there have been cases seen where valid syslog messages have come
+   from a sender with a source port other than 514.  If the sender uses
+   a source port other than 514 then it is RECOMMENDED and has been
+   considered to be good form that subsequent messages are from a single
+   consistent port.
+
+3. 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 message.
+
+
+
+
+Lonvick                      Informational                      [Page 5]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+         Any relay or collector will be known as the "receiver" when it
+         receives the message.
+
+   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
+         receivers.
+
+         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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonvick                      Informational                      [Page 6]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+         +------+         +---------+
+         |Device|---->----|Collector|
+         +------+         +---------+
+
+         +------+         +-----+         +---------+
+         |Device|---->----|Relay|---->----|Collector|
+         +------+         +-----+         +---------+
+
+         +------+     +-----+            +-----+     +---------+
+         |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+         +------+     +-----+            +-----+     +---------+
+
+         +------+         +-----+         +---------+
+         |Device|---->----|Relay|---->----|Collector|
+         |      |-\       +-----+         +---------+
+         +------+  \
+                    \      +-----+         +---------+
+                     \-->--|Relay|---->----|Collector|
+                           +-----+         +---------+
+
+         +------+         +---------+
+         |Device|---->----|Collector|
+         |      |-\       +---------+
+         +------+  \
+                    \      +-----+         +---------+
+                     \-->--|Relay|---->----|Collector|
+                           +-----+         +---------+
+
+         +------+         +-----+            +---------+
+         |Device|---->----|Relay|---->-------|Collector|
+         |      |-\       +-----+         /--|         |
+         +------+  \                     /   +---------+
+                    \      +-----+      /
+                     \-->--|Relay|-->--/
+                           +-----+
+
+           Diagram 1.  Some Possible syslog Architectures
+
+4. Packet Format and Contents
+
+   The payload of any IP packet that has a UDP destination port of 514
+   MUST be treated as a syslog message.  There MAY be differences
+   between the format of an originally transmitted syslog message and
+   the format of a relayed message.  In essence, it is RECOMMENDED to
+   transmit a syslog message in the format specified in this document,
+   but it is not required.  If a relay is able to recognize the message
+   as adhering to that format then it MUST retransmit the message
+   without making any changes to it.  However, if a relay receives a
+
+
+
+Lonvick                      Informational                      [Page 7]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   message but cannot discern the proper implementation of the format,
+   it is REQUIRED to modify the message so that it conforms to that
+   format before it retransmits it.  Section 4.1 will describe the
+   RECOMMENDED format for syslog messages.  Section 4.2 will describe
+   the requirements for originally transmitted messages and Section 4.3
+   will describe the requirements for relayed messages.
+
+4.1 syslog Message Parts
+
+   The full format of a syslog message seen on the wire has three
+   discernable parts.  The first part is called the PRI, the second part
+   is the HEADER, and the third part is the MSG.  The total length of
+   the packet MUST be 1024 bytes or less.  There is no minimum length of
+   the syslog message although sending a syslog packet with no contents
+   is worthless and SHOULD NOT be transmitted.
+
+4.1.1 PRI Part
+
+   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), followed by a
+   number, which is followed by a ">" ('greater-than' character). The
+   code set used in this part MUST be seven-bit ASCII in an eight-bit
+   field as described in RFC 2234 [2].  These are the ASCII codes as
+   defined in "USA Standard Code for Information Interchange" [3].  In
+   this, the "<" character is defined as the Augmented Backus-Naur Form
+   (ABNF) %d60, and the ">" character has ABNF value %d62.  The number
+   contained within these angle brackets is known as the Priority value
+   and represents both the Facility and Severity as described below.
+   The Priority value consists of one, two, or three decimal integers
+   (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
+
+   The Facilities and Severities of the messages are numerically coded
+   with decimal values.  Some of the operating system daemons and
+   processes have been assigned Facility values.  Processes and daemons
+   that have not been explicitly assigned a Facility may use any of the
+   "local use" facilities or they may use the "user-level" Facility.
+   Those Facilities that have been designated are shown in the following
+   table along with their numerical code values.
+
+       Numerical             Facility
+          Code
+
+           0             kernel messages
+           1             user-level messages
+           2             mail system
+           3             system daemons
+           4             security/authorization messages (note 1)
+
+
+
+Lonvick                      Informational                      [Page 8]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+           5             messages generated internally by syslogd
+           6             line printer subsystem
+           7             network news subsystem
+           8             UUCP subsystem
+           9             clock daemon (note 2)
+          10             security/authorization messages (note 1)
+          11             FTP daemon
+          12             NTP subsystem
+          13             log audit (note 1)
+          14             log alert (note 1)
+          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
+
+        Note 1 - Various operating systems have been found to utilize
+           Facilities 4, 10, 13 and 14 for security/authorization,
+           audit, and alert messages which seem to be similar.
+        Note 2 - Various operating systems have been found to utilize
+           both Facilities 9 and 15 for clock (cron/at) messages.
+
+   Each message Priority also has a decimal Severity level indicator.
+   These are described in the following table along with their numerical
+   values.
+
+        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
+
+
+
+
+
+
+Lonvick                      Informational                      [Page 9]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   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 part 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" will follow the "<"
+   is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be
+   used.
+
+4.1.2 HEADER Part of a syslog Packet
+
+   The HEADER part contains a timestamp and an indication of the
+   hostname or IP address of the device.  The HEADER part of the syslog
+   packet MUST contain visible (printing) characters.  The code set used
+   MUST also be seven-bit ASCII in an eight-bit field like that used in
+   the PRI part.  In this code set, the only allowable characters are
+   the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).
+
+   The HEADER contains two fields called the TIMESTAMP and the HOSTNAME.
+   The TIMESTAMP will immediately follow the trailing ">" from the PRI
+   part and single space characters MUST follow each of the TIMESTAMP
+   and HOSTNAME fields.  HOSTNAME will contain the hostname, as it knows
+   itself.  If it does not have a hostname, then it will contain its own
+   IP address.  If a device has multiple IP addresses, it has usually
+   been seen to use the IP address from which the message is
+   transmitted.  An alternative to this behavior has also been seen.  In
+   that case, a device may be configured to send all messages using a
+   single source IP address regardless of the interface from which the
+   message is sent.  This will provide a single consistent HOSTNAME for
+   all messages sent from a device.
+
+   The TIMESTAMP field is the local time and is in the format of "Mmm dd
+   hh:mm:ss" (without the quote marks) where:
+
+         Mmm is the English language abbreviation for the month of the
+         year with the first character in uppercase and the other two
+         characters in lowercase.  The following are the only acceptable
+         values:
+
+         Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
+
+         dd is the day of the month.  If the day of the month is less
+         than 10, then it MUST be represented as a space and then the
+         number.  For example, the 7th day of August would be
+         represented as "Aug  7", with two spaces between the "g" and
+         the "7".
+
+
+
+Lonvick                      Informational                     [Page 10]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+         hh:mm:ss is the local time.  The hour (hh) is represented in a
+         24-hour format.  Valid entries are between 00 and 23,
+         inclusive.  The minute (mm) and second (ss) entries are between
+         00 and 59 inclusive.
+
+   A single space character MUST follow the TIMESTAMP field.
+
+   The HOSTNAME field will contain only the hostname, the IPv4 address,
+   or the IPv6 address of the originator of the message.  The preferred
+   value is the hostname.  If the hostname is used, the HOSTNAME field
+   MUST contain the hostname of the device as specified in STD 13 [4].
+   It should be noted that this MUST NOT contain any embedded spaces.
+   The Domain Name MUST NOT be included in the HOSTNAME field.  If the
+   IPv4 address is used, it MUST be shown as the dotted decimal notation
+   as used in STD 13 [5].  If an IPv6 address is used, any valid
+   representation used in RFC 2373 [6] MAY be used.  A single space
+   character MUST also follow the HOSTNAME field.
+
+4.1.3 MSG Part of a syslog Packet
+
+   The MSG part will fill the remainder of the syslog packet.  This will
+   usually contain some additional information of the process that
+   generated the message, and then the text of the message.  There is no
+   ending delimiter to this part.  The MSG part of the syslog packet
+   MUST contain visible (printing) characters.  The code set
+   traditionally and most often used has also been seven-bit ASCII in an
+   eight-bit field like that used in the PRI and HEADER parts.  In this
+   code set, the only allowable characters are the ABNF VCHAR values
+   (%d33-126) and spaces (SP value %d32).  However, no indication of the
+   code set used within the MSG is required, nor is it expected.  Other
+   code sets MAY be used as long as the characters used in the MSG are
+   exclusively visible characters and spaces similar to those described
+   above.  The selection of a code set used in the MSG part SHOULD be
+   made with thoughts of the intended receiver.  A message containing
+   characters in a code set that cannot be viewed or understood by a
+   recipient will yield no information of value to an operator or
+   administrator looking at it.
+
+   The MSG part has two fields known as the TAG field and the CONTENT
+   field.  The value in the TAG field will be the name of the program or
+   process that generated the message.  The CONTENT contains the details
+   of the message.  This has traditionally been a freeform message that
+   gives some detailed information of the event.  The TAG is a string of
+   ABNF alphanumeric characters that MUST NOT exceed 32 characters.  Any
+   non-alphanumeric character will terminate the TAG field and will be
+   assumed to be the starting character of the CONTENT field.  Most
+   commonly, the first character of the CONTENT field that signifies the
+
+
+
+
+Lonvick                      Informational                     [Page 11]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   conclusion of the TAG field has been seen to be the left square
+   bracket character ("["), a colon character (":"), or a space
+   character.  This is explained in more detail in Section 5.3.
+
+4.2 Original syslog Packets Generated by a Device
+
+   There are no set requirements on the contents of the syslog packet as
+   it is originally sent from a device.  It should be reiterated here
+   that the payload of any IP packet destined to UDP port 514 MUST be
+   considered to be a valid syslog message.  It is, however, RECOMMENDED
+   that the syslog packet have all of the parts described in Section 4.1
+   - PRI, HEADER and MSG - as this enhances readability by the recipient
+   and eliminates the need for a relay to modify the message.
+
+   For implementers that do choose to construct syslog messages with the
+   RECOMMENDED format, the following guidance is offered.
+
+         If the originally formed message has a TIMESTAMP in the HEADER
+         part, then it SHOULD be the local time of the device within its
+         timezone.
+
+         If the originally formed message has a HOSTNAME field, then it
+         will contain the hostname as it knows itself.  If it does not
+         have a hostname, then it will contain its own IP address.
+
+         If the originally formed message has a TAG value, then that
+         will be the name of the program or process that generated the
+         message.
+
+4.3 Relayed syslog Packets
+
+   When a relay receives a packet, it will check for a valid PRI.  If
+   the first character is not a less-than sign, the relay MUST assume
+   that the packet does not contain a valid PRI.  If the 3rd, 4th, or
+   5th character is not a right angle bracket character, the relay again
+   MUST assume that the PRI was not included in the original message.
+   If the relay does find a valid PRI part then it must check for a
+   valid TIMESTAMP in the HEADER part.  From these rules, there will be
+   three general cases of received messages.  Table 3 gives the general
+   characteristics of these cases and lists the subsequent section of
+   this document that describes the handling of that case.
+
+              Case                                         Section
+         Valid PRI and TIMESTAMP                            4.3.1
+         Valid PRI but no TIMESTAMP or invalid TIMESTAMP    4.3.2
+         No PRI or unidentifiable PRI                       4.3.3
+
+              Table 3. Cases of Received syslog Messages
+
+
+
+Lonvick                      Informational                     [Page 12]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+4.3.1 Valid PRI and TIMESTAMP
+
+   If the relay does find a valid PRI and a valid TIMESTAMP, then it
+   will check its internal configuration.  Relays MUST be configured to
+   forward syslog packets on the basis of their Priority value.  If the
+   relay finds that it is configured to forward the received packet,
+   then it MUST do so without making any changes to the packet.  To
+   emphasize the point one more time, it is for this reason that it is
+   RECOMMENDED that the syslog message originally transmitted adhere to
+   the format described in Section 4.1.
+
+   It should be noted here that the message receiver does not need to
+   validate the time in the TIMESTAMP field.  The assumption may be made
+   that a device whose date has not been correctly set will still have
+   the ability to send valid syslog messages.  Additionally, the relay
+   does not need to validate that the value in the HOSTNAME field
+   matches the hostname or IP address of the device sending the message.
+   A reason for this behavior may be found in Section 4.1.2.
+
+4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP
+
+   If a relay does not find a valid TIMESTAMP in a received syslog
+   packet, then it MUST add a TIMESTAMP and a space character
+   immediately after the closing angle bracket of the PRI part.  It
+   SHOULD additionally add a HOSTNAME and a space character after the
+   TIMESTAMP.  These fields are described here and detailed in Section
+   4.1.2.  The remainder of the received packet MUST be treated as the
+   CONTENT field of the MSG and appended.  Since the relay would have no
+   way to determine the originating process from the device that
+   originated the message, the TAG value cannot be determined and will
+   not be included.
+
+   The TIMESTAMP will be the current local time of the relay.
+
+   The HOSTNAME will be the name of the device, as it is known by the
+   relay.  If the name cannot be determined, the IP address of the
+   device will be used.
+
+   If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the
+   PRI part, then it MUST check that the total length of the packet is
+   still 1024 bytes or less.  If the packet has been expanded beyond
+   1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.
+   This may cause the loss of vital information from the end of the
+   original packet.  It is for this reason that it is RECOMMENDED that
+   the PRI and HEADER parts of originally generated syslog packets
+   contain the values and fields documented in Section 4.1.
+
+
+
+
+
+Lonvick                      Informational                     [Page 13]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+4.3.3 No PRI or Unidentifiable PRI
+
+   If the relay receives a syslog message without a PRI, or with an
+   unidentifiable PRI, then it MUST insert a PRI with a Priority value
+   of 13 as well as a TIMESTAMP as described in Section 4.3.2.  The
+   relay SHOULD also insert a HOSTNAME as described in Section 4.3.2.
+   The entire contents of the received packet will be treated as the
+   CONTENT of the relayed MSG and appended.
+
+   An example of an unidentifiable PRI would be "<00>", without the
+   double quotes.  It may be that these are the first 4 characters of
+   the message.  To continue this example, if a relay does receive a
+   syslog message with the first four characters of "<00>", then it will
+   consult its configuration.  If it is configured to forward syslog
+   messages with a Priority value of 13 to another relay or collector,
+   then it MUST modify the packet as described above.  The specifics of
+   doing this, including the RECOMMENDED insertion of the HOSTNAME, are
+   given below.
+
+   Originally received message
+     <00>...
+   Relayed message
+     <13>TIMESTAMP HOSTNAME <00>...
+
+   If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the
+   PRI part, then it MUST check that the total length of the packet is
+   still 1024 bytes or less.  If the packet has been expanded beyond
+   1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.
+   This may cause the loss of vital information from the end of the
+   original packet.  It is for this reason that it is RECOMMENDED that
+   the PRI and HEADER parts of originally generated syslog packets
+   contain the values and fields documented in Section 4.1.
+
+5. Conventions
+
+   Although Section 4 of this document specifies all requirements for
+   the syslog protocol format and contents, certain conventions have
+   come about over time for the inclusion of additional information
+   within the syslog message.  It must be plainly stated that these
+   items are not mandated but may be considered by implementers for
+   completeness and to give the recipient some additional clues of their
+   origin and nature.
+
+
+
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 14]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+5.1 Dates and Times
+
+   It has been found that some network administrators like to archive
+   their syslog messages over long periods of time.  It has been seen
+   that some original syslog messages contain a more explicit time stamp
+   in which a 2 character or 4 character year field immediately follows
+   the space terminating the TIMESTAMP.  This is not consistent with the
+   original intent of the order and format of the fields.  If
+   implementers wish to contain a more specific date and time stamp
+   within the transmitted message, it should be within the CONTENT
+   field.  Implementers may wish to utilize the ISO 8601 [7] date and
+   time formats if they want to include more explicit date and time
+   information.
+
+   Additional methods to address this desire for long-term archiving
+   have been proposed and some have been successfully implemented.  One
+   such method is that the network administrators may choose to modify
+   the messages stored on their collectors.  They may run a simple
+   script to add the year, and any other information, to each stored
+   record.  Alternatively, the script may replace the stored time with a
+   format more appropriate for the needs of the network administrators.
+   Another alternative has been to insert a record into the file that
+   contains the current year.  By association then, all other records
+   near that informative record should have been received in that same
+   year.  Neither of these however, addresses the issue of associating a
+   correct timezone with each record.
+
+5.2 Domain Name and Address
+
+   To readily identify the device that originated the message, it may be
+   a good practice to include its fully qualified domain name (FQDN) and
+   its IP address within the CONTENT field.  Traditionally, however,
+   only the hostname has been included in the HOSTNAME field.
+
+5.3 Originating Process Information
+
+   It has also been considered to be a good practice to include some
+   information about the process on the device that generated the
+   message - if that concept exists.  This is usually the process name
+   and process id (often known as the "pid") for robust operating
+   systems.  The process name is commonly displayed in the TAG field.
+   Quite often, additional information is included at the beginning of
+   the CONTENT field.  The format of "TAG[pid]:" - without the quote
+   marks - is common.  The left square bracket is used to terminate the
+   TAG field in this case and is then the first character in the CONTENT
+   field.  If the process id is immaterial, it may be left off.
+
+
+
+
+
+Lonvick                      Informational                     [Page 15]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   In that case, a colon and a space character usually follow the TAG.
+   This would be displayed as "TAG: " without the quotes.  In that case,
+   the colon is the first character in the CONTENT field.
+
+5.4 Examples
+
+   As examples, these are valid messages as they may be observed on the
+   wire between two devices.  In the following examples, each message
+   has been indented, with line breaks inserted in this document for
+   readability.
+
+        Example 1
+
+        <34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
+        on /dev/pts/8
+
+   This example shows an authentication error in an attempt to acquire
+   additional privileges.  It also shows the command attempted and the
+   user attempting it.  This was recorded as an original message from
+   the device called mymachine.  A relay receiving this would not make
+   any changes before sending it along as it contains a properly
+   formatted PRI part and TIMESTAMP field in the HEADER part.  The TAG
+   value in this example is the process "su".  The colon has terminated
+   the TAG field and is the first character of the CONTENT field.  In
+   this case, the process id (pid) would be considered transient and
+   anyone looking at this syslog message would gain no useful
+   information from knowing the pid.  It has not been included so the
+   first two characters of the CONTENT field are the colon and a space
+   character.
+
+        Example 2
+
+        Use the BFG!
+
+   While this is a valid message, it has extraordinarily little useful
+   information.  This message does not have any discernable PRI part. It
+   does not contain a timestamp or any indication of the source of the
+   message.  If this message is stored on paper or disk, subsequent
+   review of the message will not yield anything of value.
+
+   This example is obviously an original message from a device.  A relay
+   MUST make changes to the message as described in Section 4.3 before
+   forwarding it.  The resulting relayed message is shown below.
+
+        <13>Feb  5 17:32:18 10.0.0.99 Use the BFG!
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 16]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   In this relayed message, the entire message has been treated as the
+   CONTENT portion of the MSG part.  First, a valid PRI part has been
+   added using the default priority value of 13.  Next, a TIMESTAMP has
+   been added along with a HOSTNAME in the HEADER part.  Subsequent
+   relays will not make any further changes to this message.  It should
+   be noted in this example that the day of the month is less than 10.
+   Since single digits in the date (5 in this case) are preceded by a
+   space in the TIMESTAMP format, there are two spaces following the
+   month in the TIMESTAMP before the day of the month.  Also, the relay
+   appears to have no knowledge of the host name of the device sending
+   the message so it has inserted the IPv4 address of the device into
+   the HOSTNAME field.
+
+        Example 3
+
+         <165>Aug 24 05:34:00 CST 1987 mymachine 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 message does have a valid PRI part with a Priority value
+   indicating that it came from a locally defined facility (local4) with
+   a severity of Notice.  The HEADER part has a proper TIMESTAMP field
+   in the message.  A relay will not modify this message before sending
+   it.  However, the HOSTNAME and TAG fields are not consistent with the
+   definitions in Section 4.  The HOSTNAME field would be construed to
+   be "CST" and the beginning of the MSG part would be "1987".
+
+   It should be noted that the information contained in the CONTENT of
+   this example is not telemetry data, nor is it supervisory control or
+   data acquisition information.  Due to the security concerns listed in
+   Section 6 of this document, information of that nature should
+   probably not be conveyed across this protocol.
+
+        Example 4
+
+         <0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
+         sched[0]: That's All Folks!
+
+   This example has a lot of extraneous information throughout.  A human
+   or sufficiently adaptable automated parser would be able to determine
+   the date and time information as well as a fully qualified domain
+   name (FQDN) [4] and IP address.  The information about the nature of
+   the event is, however, limited.  Due to the indicated severity of the
+   event, the process may not have been able to gather or send anything
+   more informative.  It may have been fortunate to have generated and
+   sent this message at all.
+
+
+
+
+Lonvick                      Informational                     [Page 17]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   This example is obviously an original message from a device.  Since
+   the first field in the HEADER part is not a TIMESTAMP in the format
+   defined in Section 4.1.2, it MUST be modified by a relay.  A relay
+   will add a TIMESTAMP and SHOULD add a HOSTNAME as follows and will
+   treat the entire received packet after the PRI part from the original
+   packet as the CONTENT field of the new packet.  The value used in the
+   HOSTNAME field is only the hostname without the domain name as it is
+   known by the relay.  A TAG value will not be added to the relayed
+   packet.  While the inclusion of the domain name and IPv4 address in
+   the original message is a noble endeavor, it is not consistent with
+   the use of the field as described in Section 4.1.2.
+
+         <0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6
+         scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
+
+6. Security Considerations
+
+   An odor may be considered to be a message that does not require any
+   acknowledgement.  People tend to avoid bad odors but are drawn to
+   odors that they associate with good food.  The acknowledgement of the
+   receipt of the odor or scent is not required and indeed it may be the
+   height of discretion to totally ignore some odors.  On the other
+   hand, it is usually considered good civility to acknowledge the
+   prowess of the cook merely from the ambiance wafting from the
+   kitchen.  Similarly, various species have been found to utilize odors
+   to attract mates.  One species of moth uses this scent to find each
+   other.  However, it has been found that bolas spiders can mimic the
+   odor of the female moths of this species.  This scent will then
+   attract male moths, which will follow it with the expectation of
+   finding a mate.  Instead, when they arrive at the source of the
+   scent, they will be eaten [8].  This is a case of a false message
+   being sent out with inimical intent.
+
+   In its local use, the syslog process places event notification
+   messages into files on that system.  This relies upon the integrity
+   of the system for the protection of the messages.  The subsequent
+   configuration of the syslog process to use the syslog protocol to
+   transport the messages to a remote collector was an extension of the
+   delivery of event notification messages and it exhibits the same
+   trust of the network.  There are several security consequences of the
+   fundamental simplicity of syslog and there are some concerns about
+   the applicability of this protocol in situations that require robust
+   delivery.  Along the lines of the analogy, computer event messages
+   may be sent accidentally, erroneously and even maliciously. At the
+   time of this writing, however, there have not been any reports of any
+   networked device consuming any other device.
+
+
+
+
+
+Lonvick                      Informational                     [Page 18]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+6.1 Packet Parameters
+
+   As was described above, the message length MUST NOT exceed 1024
+   bytes.  Attacks have seen where syslog messages are sent to a
+   receiver that have message lengths greater than 1024 bytes.  In some
+   older versions of syslog, the receipt of syslog packets that had a
+   message greater than 1024 bytes caused problems.  syslog message
+   receivers must not malfunction upon the receipt of packets where the
+   message length is greater than 1024 bytes.  Various behaviors have
+   been seen on receivers that do receive messages greater than 1024
+   bytes.  Some have been seen to log the entire contents of the
+   message, while others have been seen to log only portions of the
+   message.  Still others have been known to discard the message
+   altogether.  Devices MUST NOT retransmit messages whose received
+   length exceeds 1024 bytes.
+
+   Similarly, the receiver must rigidly enforce the correctness of the
+   message body.  syslog collectors must not malfunction if received
+   messages do not have the less-than and greater-than characters around
+   a valid Priority value.  They MUST treat these messages as the
+   unformatted CONTENT as was described in Section 4.3.3 if they relay
+   it.
+
+   Also, received messages must contain printable text in the message as
+   was described throughout Section 4.  Devices must not malfunction if
+   they receive a message containing characters other than the
+   characters described above.
+
+6.2 Message Authenticity
+
+   The syslog delivery mechanism does not strongly associate the message
+   with the message sender.  The receiver of that packet will not be
+   able to ascertain that the message was indeed sent from the reported
+   sender, or if the packet was sent from another device.  It should be
+   noted here that the message receiver does not need to verify that the
+   HOSTNAME in the HEADER part match the name of the IP address
+   contained in the Source Address field of the IP packet.
+
+6.2.1 Authentication Problems
+
+   One possible consequence of this behavior is that a misconfigured
+   machine may send syslog messages to a collector representing itself
+   as another machine.  The administrative staff may become confused
+   that the status of the supposed sender of the messages may not be
+   accurately reflected in the received messages.  The administrators
+   may not be able to readily discern that there are two or more
+   machines representing themselves as the same machine.
+
+
+
+
+Lonvick                      Informational                     [Page 19]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   It should also be noted that some cases of filling the HOSTNAME field
+   in the HEADER part might only have local significance and that may
+   only be ephemeral.  If the device had obtained an IP address from a
+   DHCP pool, then any association between an identifier and an actual
+   source would not always hold true.  The inclusion of a fully
+   qualified domain name in the CONTENT may give the administrators the
+   best chance of identifying the source of each message if it can
+   always be associated with an IP address or if it can always be
+   associated with a unique machine.
+
+6.2.2 Message Forgery
+
+   Malicious exploits of this behavior have also been noted.  An
+   attacker may transmit syslog messages (either from the machine from
+   which the messages are purportedly sent or from any other machine) to
+   a collector.  In one case, an attacker may hide the true nature of an
+   attack amidst many other messages.  As an example, an attacker may
+   start generating forged messages indicating a problem on some
+   machine.  This may get the attention of the system administrators who
+   will spend their time investigating the alleged problem.  During this
+   time, the attacker may be able to compromise a different machine, or
+   a different process on the same machine.  Additionally, an attacker
+   may generate false syslog messages to give untrue indications of
+   status or of events.  As an example, an attacker may stop a critical
+   process on a machine, which may generate a notification of exit.  The
+   attacker may subsequently generate a forged notification that the
+   process had been restarted.  The system administrators may accept
+   that misinformation and not verify that the process had indeed been
+   restarted.
+
+6.3 Sequenced Delivery
+
+   As a general rule, the forensics of a network anomaly rely upon
+   reconstructing the sequence of events.  In a perfect world, the
+   messages would be received on the syslog collector in the order of
+   their generation from the other devices and anyone looking at these
+   records would have an accurate picture of the sequence of events.
+   Unfortunately, the syslog process and protocol do not ensure ordered
+   delivery.  This section details some of the problems that may be
+   encountered from this.
+
+6.3.1 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 transported across an IP network, some out of
+   order receipt should be expected.  This may lead to some confusion as
+
+
+
+Lonvick                      Informational                     [Page 20]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   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.
+
+6.3.2 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.
+
+6.3.3 Multiple Sources to Multiple Destinations
+
+   The plethora of configuration options available to the network
+   administrators may further skew the perception of the order of
+   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.
+
+
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 21]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+6.3.4 Replaying
+
+   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.
+
+6.4 Reliable Delivery
+
+   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.
+
+6.5 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.
+
+6.6 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
+
+
+
+Lonvick                      Informational                     [Page 22]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   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.
+
+6.7 Message Prioritization and Differentiation
+
+   While the processes that create the messages may signify the
+   importance of the events through the use of the message Priority
+   value, there is no distinct association between this value and the
+   importance of delivery of the packet.  As an example of this,
+   consider an application that generates two event messages.  The first
+   is a normal status message but the second could be an important
+   message denoting a problem with the process.  This second message
+   would have an appropriately higher Severity value associated with the
+   importance of that event.  If the operators had configured that both
+   of these messages be transported to a syslog collector then they
+   would, in turn, be given to UDP for transmission.  Under normal
+   conditions, no distinction would be made between them and they would
+   be transmitted in their order.
+
+   Again, under normal circumstances, the receiver would accept syslog
+   messages as they are received.  If many devices are transmitting
+   normal status messages, but one is transmitting an important event
+   message, there is no inherent mechanism within the syslog protocol to
+   prioritize the important message over the other messages.
+
+   On a case-by-case basis, device operators may find some way to
+   associate the different levels with the quality of service
+   identifiers.  As an example, the operators may elect to define some
+   linkage between syslog messages that have a specific Priority value
+   with a specific value to be used in the IPv4 Precedence field [9],
+   the IPv6 Traffic Class octet [11], or the Differentiated Services
+   field [12].  In the above example, the operators may have the ability
+   to associate the status message with normal delivery while
+   associating the message indicating a problem with a high reliability,
+   low latency queue as it goes through the network.  This would have
+   the affect of prioritizing the essential messages before the normal
+   status messages.  Even with this hop-by-hop prioritization, this
+   queuing mechanism could still lead to head of line blocking on the
+   transmitting device as well as buffer starvation on the receiving
+
+
+
+Lonvick                      Informational                     [Page 23]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   device if there are many near-simultaneous messages being sent or
+   received.  This behavior is not unique to syslog but is endemic to
+   all operations that transmit messages serially.
+
+   There are security concerns for this behavior.  Head of line blocking
+   of the transmission of important event messages may relegate the
+   conveyance of important messages behind less important messages.  If
+   the queue is cleared appropriately, this may only add seconds to the
+   transmission of the important message.  On the other hand, if the
+   queue is not cleared, then important messages may not be transmitted.
+   Also at the receiving side, if the syslog receiver is suffering from
+   buffer starvation due to large numbers of messages being received
+   near-simultaneously, important messages may be dropped
+   indiscriminately along with other messages.  While these are problems
+   with the devices and their capacities, the protocol security concern
+   is that there is no prioritization of the relatively more important
+   messages over the less important messages.
+
+6.8 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.
+
+6.9 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.
+
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 24]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+6.10 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
+   links.
+
+7. IANA Considerations
+
+   The syslog protocol has been assigned UDP port 514.  This port
+   assignment will be maintained by IANA exclusively for this protocol.
+
+   The syslog protocol provides for the definition of named attributes
+   to indicate the Severity of each message and the Facility that
+   generated the message as described in Section 4.  The name space
+   identifiers for these attributes are defined as numbers.  The
+   protocol does not define the specific assignment of the name space
+   for these numbers; the application developer or system vendor is
+   allowed to define the attribute, its semantics, and the associated
+   numbers.  This name space will not be controlled to prevent
+   collisions as systems are expected to use the same attributes,
+   semantics and associated numbers to describe events that are deemed
+   similar even between heterogeneous devices.
+
+8. Conclusion and Other Efforts
+
+   The syslog protocol may be effectively used to transport event
+   notification messages across a network.  In all cases, it is
+   important that the syslog message receiver embody the principle of
+   "be liberal in what you accept".  It is highly recommended that the
+   network operators who choose to use this understand the
+   characteristics of the protocol and its security implications.
+
+   There have been attempts in the past to standardize the format of the
+   syslog message.  The most notable attempt culminated in a BOF at the
+   Fortieth Internet Engineering Task Force meeting in 1997.  This was
+   the Universal Logging Protocol (ulp) BOF and the minutes of their
+   meeting are on-line at the IETF Proceedings web site [14].
+
+
+
+
+Lonvick                      Informational                     [Page 25]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   Many good thoughts came from that effort and interested implementers
+   may want to find some of the notes or papers produced from that
+   effort.
+
+   At the time of this writing, efforts are underway to allow the usage
+   of international character sets in applications that have been
+   traditionally thought of as being text-only.  The HOSTNAME and
+   TIMESTAMP fields described above are representative of this.  Also,
+   the entire CONTENT field has traditionally been printing characters
+   and spaces in the code set known as US-ASCII.  It is hoped that the
+   proponents of these internationalization efforts will find a suitable
+   way to allow the use of international character sets within syslog
+   messages without being disruptive.  It should also be hoped that
+   implementers will allow for the future acceptance of additional code
+   sets and that they may make appropriate plans.  Again, it must be
+   cautioned that the simplicity of the existing system has been a
+   tremendous value to its acceptance.  Anything that lessens that
+   simplicity may diminish that value.
+
+Acknowledgements
+
+   The following people provided content feedback during the writing of
+   this document:
+
+         Jon Knight <J.P.Knight@lboro.ac.uk>
+         Magosanyi Arpad <mag@bunuel.tii.matav.hu>
+         Balazs Scheidler <bazsi@balabit.hu>
+         Jon Callas <jon@counterpane.com>
+         Eliot Lear <lear@cisco.com>
+         Petter Reinholdtsen <pere@hungry.com>
+         Darren Reed <darrenr@reed.wattle.id.au>
+         Alfonso De Gregorio <dira@speedcom.it>
+         Eric Allman <eric@sendmail.com>
+         Andrew Ross <andrew@kiwi-enterprises.com>
+         George Maslyar <george.maslyar@primark.com>
+         Albert Mietus <albert@ons-huis.net>
+         Russ Allbery <rra@stanford.edu>
+         Titus D. Winters <titus@cs.hmc.edu>
+         Edwin P. Boon <Edwin.Boon@consul.com>
+         Jeroen M. Mostert <Jeroen.Mostert@consul.com>
+
+   Eric Allman is the original inventor and author of the syslog daemon
+   and protocol.  The author of this memo and the community at large
+   would like to express their appreciation for this work and for the
+   usefulness that it has provided over the years.
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 26]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   A large amount of additional information about this de-facto standard
+   operating system feature may usually be found in the syslog.conf file
+   as well as in the man pages for syslog.conf, syslog, syslogd, and
+   logger, of many Unix and Unix-like devices.
+
+References
+
+   1  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
+
+   2  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, November 1997.
+
+   3  USA Standard Code for Information Interchange, USASI X3.4-1968
+
+   4  Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13,
+      RFC 1034, November 1987.
+
+   5  Mockapetris, P., "Domain names - Implementation and
+      Specification", STD 13, RFC 1035, November 1987.
+
+   6  Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",
+      RFC 2373, July 1998.
+
+   7  Data elements and interchange formats - Information exchange -
+      Representation of dates and times, International Organization for
+      Standardization, Reference number ISO 8601 : 1988 (E), 1988
+
+   8  Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components
+      of Moth Prey Species Sex Pheromones", Science, 1987
+
+   9  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+   10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June
+      1995.
+
+   11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+      Specification", RFC 2460, December 1998.
+
+   12 Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the
+      Differentiated Services Field (DS Field) in the IPv4 and IPv6
+      Headers", RFC 2474, December 1998.
+
+   13 Cisco Systems Product Security Incident Response Team (PSIRT),
+      "Field Notice: Cisco IOS(r) Syslog Crash", January 11, 1999
+      http://www.cisco.com/warp/public/707/advisory.html
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 27]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+   14 Walker, D., IETF Secretariat, "Proceedings of the Fortieth
+      Internet Engineering Task Force, Washington, DC, USA, December 8-
+      12, 1997
+      http://www.ietf.org/proceedings/97dec/index.html
+
+Author's Address
+
+   Chris Lonvick
+   Cisco Systems
+   12515 Research Blvd.
+   Austin, TX, USA
+
+   Phone:  +1.512.378.1182
+   EMail:  clonvick@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 28]
+
+RFC 3164                The BSD syslog Protocol              August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonvick                      Informational                     [Page 29]
+