This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2004.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document describes the UDP transport for the syslog protocol.
2. Requirements notation
3. Definitions and Architecture
4. Required Transport Protocol
5. Datagram Content
7. IP Layer
8. Reliability Considerations
8.1 Lost Datagrams
8.2 Message Corruption and Checksums
8.3 Congestion Control
8.4 Sequenced Delivery
8.5 IP Fragmentation
9. Security Considerations
9.1 Message Authenticity
9.2 Authentication Problems
9.3 Message Forgery
9.4 Message Observation
9.6 Reliable Delivery
9.7 Message Prioritization and Differentiation
9.8 Denial of Service
9.9 Covert Channels
10. IANA Considerations
11. Notice to RFC Editor
12. Authors and Working Group Chair
§ Author's Address
§ Intellectual Property and Copyright Statements
The original syslog protocol has been described in an informational RFC 3164 as it has been observed in existing implementations. Subsequently, the syslog protocol has been formally described in a standards track RFC-protocol, which obsoleted RFC 3164.
The RFC-protocol has provided for support of any number of transport layer protocols for transmitting syslog messages and left it to subsequent RFCs to specify transport protocols.
This standards track RFC describes the UDP transport for the syslog protocol and establishes this transport protocol as REQUIRED for all syslog protocol implementations. The UDP protocol has been described in RFC 768 and additional clarifications have been provided in RFC 1122.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The following definitions will be used in this document:
An application that can generate syslog messages will be called a "client";
An application that can receive syslog messages will be called a "server".
A given host or an application can function in dual capacity. For example, a syslog relay may receive and forward messages. In this case, the relay is functioning as a server when receiving messages and as a client when sending messages it intends to forward.
This document describes the UDP transport layer protocol for the syslog protocol RFC-protocol. Every syslog client and server implementation which adheres to the RFC-protocol, MUST implement the UDP transport protocol specified in this document.
Each syslog message MUST be transmitted in a separate UDP datagram.
When syslog messages are broken into multiple parts as permitted in the RFC-protocol, then each syslog message part MUST be sent in a separate datagram.
Each UDP datagram MUST adhere to the structure specified in UDP RFC 768.
The UDP datagram data field MUST NOT include any extra data such as additional headers or trailer other than the well-formatted syslog message.
Syslog servers MUST support accepting syslog message datagrams on a well-known UDP port 514. Syslog clients MUST support sending syslog message datagrams to UDP port 514.
[TODO AO: Any recommendations or requirements for the IP layer?]
The UDP is an unreliable low-overhead protocol. This section discusses reliability issues inherent to the UDP that implementers and users must be aware of.
Neither UDP nor syslog protocol provide any mechanism to detect loss of datagrams and request a resend. Datagrams may be lost in transit due to congestion, corruption or any other intermittent network problem. The server and client applications may not get any notifications of such loss.
In some circumstances the client application may receive an ICMP error message or other indication of a transmission problem. If client application receives a reasonable indication that some messages could have been lost, it MAY retransmit previously sent messages. [TODO AO: Or should it be MAY NOT? Do people agree? Or will this only create potential for duplicates? Delayed ICMP message and the potential confusion in demultiplexing]
When transmitting multi-part syslog messages according to RFC-protocol, the syslog server is required to re-assemble the complete syslog message out multiple parts. In this case, if only some datagrams are missing, the server will detect the loss of datagrams. However, there is no mechanism for the syslog server to request missing syslog message datagrams. The expected behavior of the syslog server when it can not reassemble the multi-part syslog message is described in RFC-protocol.
The UDP datagrams may get corrupted in transit due to software, hardware or network errors. Some errors can be detected by the lower network (i.e. IP) or datalink (i.e. Ethernet) layers. When corruption is detected, the packet or frame is normally discarded. Typically, corruption detection features of the network and datalink layer protocols do not guarantee corruption detection in every case.
The UDP provides for an additional mechanism to detect corruption. The UDP RFC 768 provides for using checksums, but does not require them. The UDP checksums have been made mandatory by the RFC 1122. In light of potential presence of legacy infrastructure, we can not require checksums, but their use is RECOMMENDED. Syslog clients SHOULD provide the UDP checksum in each UDP datagram and syslog servers SHOULD validate checksums. Datagrams with invalid checksums SHOULD be discarded by the syslog server implementations.
Even when properly utilized, the UDP checksums do not provide an absolute guarantee of corruption detection. Users of syslog protocol must be aware of potential corruption inherent in the UDP transport.
The UDP transport does not provide for congestion control. Some systems (hosts or routers) may generate ICMP source quench error, but they are not required to according to Stevens94. Whether or not the system sends diagnostic ICMP messages, it can discard UDP packets when it is overloaded. The UDP does not have any inherent features for congestion control. Therefore, one or multiple syslog clients can maliciously or inadevertently overload the server or the network infrastructure and cause loss of syslog messages.
The IP transport utilized by the UDP does not guarantee that the sequence of datagram delivery will match the order in which the datagrams have been sent. The time stamp contained within each syslog message may serve as some guide in establishing sequence order, but it will not help in cases when multiple messages were generated during the same time slot or when messages originated from different hosts whose clocks are no synchronized. The order of syslog message arrival via the UDP transport SHOULD NOT be used as an authoritative guide in establishing the sequence of events on the syslog client hosts.
The UDP IP packets can be fragmented by the IP layer transport at the sending host or in transit in order to satisfy the Maximum Transmission Unit (MTU) size of a particular network. Fragmented packets are then reassembled into a single datagram at the syslog server host by the IP layer. Fragmentation is generally considered harmful for several reasons which have been described in Kent87. Fragmentation introduces performance overhead for fragmenting and reassembling packets. Fragmentation also increases the risk that datagram will need to be discarded by the IP layer implementation because one fragment of the datagram packet got lost.
Syslog client implementers and users SHOULD try to avoid IP fragmentation. It is RECOMMENDED that syslog messages which are transmitted using this transport are kept to a total size of 548 bytes or less. This recommendation is based on RFC 1122 Section 3.3.3 which recommends a default IP packet MTU of 576 bytes. Subtracting the IPv4 header of 20 bytes and UDP header of 8 bytes, we have 548 bytes remaining for the UDP datagram data field.
It is RECOMMENDED that syslog client implementation provide a mechanism to set the MTU size and that they fragment the IP packets according to this size. This would allow an administrator to manually configure MTU instead of relying on the IP protocol stack to auto-discover it and risk the datagrams being truncated or lost when wrong MTU is used. [TODO AO: maybe we should recommend multi-part messages instead?]
Several syslog security considerations have been discussed in RFC-protocol . This section focuses on security considerations specific to the UDP transport.
The UDP syslog transport 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.
[TODO: What about source IP? Are we losing it? Should the first server actually verify it matches what is in the message?]
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.
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.
The UDP syslog transport specified in this document does not provide confidentiality of the messages in transit. In most cases passing clear-text human-readable messages is a benefit to the administrators. 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. It is RECOMMENDED that no sensitive information is transmitted via the UDP syslog transport or that transmission of such information is restricted to properly secured network.
Message forgery and observation can be combined into a replay attack. 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 with new time stamps. The administrators may find nothing unusual in the received messages and their receipt would falsely indicate normal activity of the machine.
As was previously discussed in the Reliability Considerations section, the UDP transport is not reliable and packets containing syslog message datagrams can be dropped in transit. There can be security consequences of the loss of one or more syslog messages. 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.
The UDP syslog transport described in this document does not require prioritiziation of syslog messages on the wire or when processed on the receiving host based on their severity. The security implication of such behavior is that the syslog server or network devices may get overwhelmed with low severity messages and be forced to discard messages among which could be high severity messages. High severity messages may contain indication about serious security problems, but they will not get a higher priority. It is difficult to make sure that high severities messages get higher end-to-end delivery priority, especially over an unreliable UDP transport.
On a case-by-case basis, device operators may find some way to associate the different severity 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 , the IPv6 Traffic Class octet , or the Differentiated Services field . However, even with this prioritization on the network, high load can lead to buffer starvation on the receiving host and result in dropped messages.
An attacker may overwhelm a receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat such as only receiving syslog messages from known IP addresses. [TODO AO: move to -protocol?]
This protocol does not attempts to eliminate covert channels. Indeed, syslog message syntax could be very amenable to sending embedded secret messages. In fact, just about every aspect of syslog messages lends itself to the conveyance of covert signals. For example, a collusionist could send odd and even severity values to indicate Morse Code dashes and dots. [TODO AO: move to -protocol?]
IANA must reserve UDP port 514 for this transport.
This is a notice to the RFC editor. This ID is submitted along with ID draft-ietf-syslog-protocol and they cross-reference each other. When RFC numbers are determined for each of these IDs, please replace all references to "RFC-protocol" with the RFC number of draft-ietf-syslog-protocol ID. Please remove this section after editing.
The working group can be contacted via the mailing list:
The current Chair of the Working Group may be contacted at:
Chris Lonvick Cisco Systems Email: firstname.lastname@example.org
The author of this draft is:
Anton Okmianski Email: email@example.com Phone: (978) 936-1612 Fax: (978) 936-2225 Cisco Systems, Inc 1414 Massachusetts Ave. Boxborough, MA 01719-2205 USA
The authors wish to thank Chris Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, and all others who have commented on various versions of this proposal.
|||Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.|
|||Gerhards, R., "The syslog Protocol", RFC RFC-protocol.|
|||Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.|
|||Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.|
|||Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (HTML, XML).|
|||Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.", January 1994.|
|||Kent, C. and J. Mogul, ""Fragmentations Considered Harmful," Computer Communications Review, vol.17, no.5, pp.390-401", August 1987.|
|||Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.|
|||Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 (HTML, XML).|
|||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 (HTML, XML).|
|Cisco Systems, Inc.|
|1414 Massachusetts Ave|
|Boxborough, MA 01719-2205|
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "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.
Funding for the RFC Editor function is currently provided by the Internet Society.