syslog Working Group A. Okmianski
Internet-Draft Cisco Systems, Inc.
Expires: August 1, 2004 February 2004
Transmission of syslog messages over UDP
draft-ietf-syslog-transport-udp-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
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 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the UDP transport for the syslog protocol.
Okmianski Expires August 1, 2004 [Page 1]
Internet-Draft syslog udp transport February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Definitions and Architecture . . . . . . . . . . . . . . . . . 4
2.2 Required Transport Protocol . . . . . . . . . . . . . . . . . 4
2.3 Datagram Content . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Reliability Considerations . . . . . . . . . . . . . . . . . . 5
3.1 Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Message Corruption and Checksums . . . . . . . . . . . . . . . 5
3.3 Congestion Control . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Sequenced Delivery . . . . . . . . . . . . . . . . . . . . . . 6
3.5 IP Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . . 8
4.2 Authentication Problems . . . . . . . . . . . . . . . . . . . 8
4.3 Message Forgery . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Message Observation . . . . . . . . . . . . . . . . . . . . . 9
4.5 Replaying . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Reliable Delivery . . . . . . . . . . . . . . . . . . . . . . 9
4.7 Message Prioritization and Differentiation . . . . . . . . . . 9
4.8 Denial of Service . . . . . . . . . . . . . . . . . . . . . . 10
4.9 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 12
7. Authors and Working Group Chair . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Okmianski Expires August 1, 2004 [Page 2]
Internet-Draft syslog udp transport February 2004
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].
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].
Okmianski Expires August 1, 2004 [Page 3]
Internet-Draft syslog udp transport February 2004
2. Transport Protocol
2.1 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.
2.2 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.
2.3 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.
2.4 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. Syslog clients can use any
originating port for transmitting messages.
Okmianski Expires August 1, 2004 [Page 4]
Internet-Draft syslog udp transport February 2004
3. 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.
3.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.
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].
3.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
Okmianski Expires August 1, 2004 [Page 5]
Internet-Draft syslog udp transport February 2004
absolute guarantee of corruption detection. Users of syslog protocol
must be aware of potential corruption inherent in the UDP transport.
3.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 do so according to Stevens94 [6].
Regardless of 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 legitimate syslog messages.
3.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 not 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.
3.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.
Okmianski Expires August 1, 2004 [Page 6]
Internet-Draft syslog udp transport February 2004
It is RECOMMENDED that syslog client implementations 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.
Okmianski Expires August 1, 2004 [Page 7]
Internet-Draft syslog udp transport February 2004
4. Security Considerations
Several syslog security considerations have been discussed in
RFC-protocol [2] . This section focuses on security considerations
specific to the UDP transport.
4.1 Message Authenticity
The UDP syslog transport does not strongly associate the message with
the message sender. The receiver of the syslog message 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 field in the syslog HEADER matches the name of the IP
address contained in the Source Address field of the IP packet.
4.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.
4.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.
Okmianski Expires August 1, 2004 [Page 8]
Internet-Draft syslog udp transport February 2004
4.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.
4.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.
4.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.
4.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
Okmianski Expires August 1, 2004 [Page 9]
Internet-Draft syslog udp transport February 2004
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.
4.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.
4.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.
Okmianski Expires August 1, 2004 [Page 10]
Internet-Draft syslog udp transport February 2004
5. IANA Considerations
IANA must reserve UDP port 514 for this transport.
Okmianski Expires August 1, 2004 [Page 11]
Internet-Draft syslog udp transport February 2004
6. 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.
Okmianski Expires August 1, 2004 [Page 12]
Internet-Draft syslog udp transport February 2004
7. Authors and Working Group Chair
The working group can be contacted via the mailing list:
syslog-sec@employees.org
The current Chair of the Working Group may be contacted at:
Chris Lonvick
Cisco Systems
Email: clonvick@cisco.com
The author of this draft is:
Anton Okmianski
Email: aokmians@cisco.com
Phone: (978) 936-1612
Fax: (978) 936-2225
Cisco Systems, Inc
1414 Massachusetts Ave.
Boxborough, MA 01719-2205
USA
Okmianski Expires August 1, 2004 [Page 13]
Internet-Draft syslog udp transport February 2004
8. Acknowledgements
The author wishes to thank Chris Lonvick, Rainer Gerhards, David
Harrington, Andrew Ross, and all others who have commented on the
various versions of this proposal.
Okmianski Expires August 1, 2004 [Page 14]
Internet-Draft syslog udp transport February 2004
References
[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.
[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.
[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.
Author's Address
Anton Okmianski
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719-2205
USA
EMail: aokmians@cisco.com
Okmianski Expires August 1, 2004 [Page 15]
Internet-Draft syslog udp transport February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
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
Okmianski Expires August 1, 2004 [Page 16]
Internet-Draft syslog udp transport February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Okmianski Expires August 1, 2004 [Page 17]
