From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3164.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc3164.txt (limited to 'doc/rfc/rfc3164.txt') 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 + Magosanyi Arpad + Balazs Scheidler + Jon Callas + Eliot Lear + Petter Reinholdtsen + Darren Reed + Alfonso De Gregorio + Eric Allman + Andrew Ross + George Maslyar + Albert Mietus + Russ Allbery + Titus D. Winters + Edwin P. Boon + Jeroen M. Mostert + + 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] + -- cgit v1.2.3