syslog Working GroupA. Okmianski
Internet-DraftCisco Systems, Inc.
Expires: August 13, 2004February 13, 2004

Transmission of syslog messages over UDP


Status of this Memo

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

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

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

The list of current Internet-Drafts can be accessed at

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

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

Copyright Notice

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


This document describes the UDP transport for the syslog protocol.

Table of Contents

1.  Introduction
2.  Requirements notation
3.  Definitions and Architecture
4.  Required Transport Protocol
5.  Datagram Content
6.  Port
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.5  Replaying
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
13.  Acknowledgements
§  References
§  Author's Address
§  Intellectual Property and Copyright Statements


1. Introduction

The original syslog protocol has been described in an informational RFC 3164[1] as it has been observed in existing implementations. Subsequently, the syslog protocol has been formally described in a standards track RFC-protocol[2], which obsoleted RFC 3164[1].

The RFC-protocol[2] 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[3] and additional clarifications have been provided in RFC 1122[4].


2. Requirements notation

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


3. Definitions and Architecture

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.


4. Required Transport Protocol

This document describes the UDP transport layer protocol for the syslog protocol RFC-protocol[2]. Every syslog client and server implementation which adheres to the RFC-protocol[2], MUST implement the UDP transport protocol specified in this document.


5. Datagram Content

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[2], 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[3].

The UDP datagram data field MUST NOT include any extra data such as additional headers or trailer other than the well-formatted syslog message.


6. Port

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.


7. IP Layer

[TODO AO: Any recommendations or requirements for the IP layer?]


8. Reliability Considerations

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.

8.1 Lost Datagrams

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[2], 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[2].

8.2 Message Corruption and Checksums

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[3] provides for using checksums, but does not require them. The UDP checksums have been made mandatory by the RFC 1122[4]. 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.

8.3 Congestion Control

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

8.4 Sequenced Delivery

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.

8.5 IP Fragmentation

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[7]. 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[4] 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?]


9. Security Considerations

Several syslog security considerations have been discussed in RFC-protocol[2] . This section focuses on security considerations specific to the UDP transport.

9.1 Message Authenticity

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

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

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

9.4 Message Observation

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.

9.5 Replaying

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.

9.6 Reliable Delivery

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.

9.7 Message Prioritization and Differentiation

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 [8], the IPv6 Traffic Class octet [9], or the Differentiated Services field [10]. However, even with this prioritization on the network, high load can lead to buffer starvation on the receiving host and result in dropped messages.

9.8 Denial of Service

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

9.9 Covert Channels

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


10. IANA Considerations

IANA must reserve UDP port 514 for this transport.


11. Notice to RFC Editor

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.


12. Authors and Working Group Chair

The working group can be contacted via the mailing list:

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

  Chris Lonvick
  Cisco Systems

The author of this draft is:

  Anton Okmianski

  Phone: (978) 936-1612
  Fax: (978) 936-2225

  Cisco Systems, Inc
  1414 Massachusetts Ave.
  Boxborough, MA 01719-2205


13. Acknowledgements

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.



[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol.
[3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[4] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (HTML, XML).
[6] Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.", January 1994.
[7] Kent, C. and J. Mogul, ""Fragmentations Considered Harmful," Computer Communications Review, vol.17, no.5, pp.390-401", August 1987.
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 (HTML, XML).
[10] 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).


Author's Address

  Anton Okmianski
  Cisco Systems, Inc.
  1414 Massachusetts Ave
  Boxborough, MA 01719-2205


Intellectual Property Statement

Full Copyright Statement