syslog Working Group A. Okmianski
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track September 5, 2007
Expires: March 8, 2008
Transmission of syslog messages over UDP
draft-ietf-syslog-transport-udp-12
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the transport for syslog messages over UDP/
IPv4 or UDP/IPv6. The syslog protocol layered architecture provides
for support of any number of transport mappings. However, for
interoperability purposes, syslog protocol implementers are required
to support this transport mapping.
Okmianski Expires March 8, 2008 [Page 1]
Internet-Draft syslog udp transport September 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 3
3.1. One Message Per Datagram . . . . . . . . . . . . . . . . . 3
3.2. Message Size . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Source and Target Ports . . . . . . . . . . . . . . . . . 4
3.4. Source IP Address . . . . . . . . . . . . . . . . . . . . 4
3.5. UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . 5
3.6. UDP Checksums . . . . . . . . . . . . . . . . . . . . . . 5
4. Reliability Considerations . . . . . . . . . . . . . . . . . . 5
4.1. Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Message Corruption . . . . . . . . . . . . . . . . . . . . 5
4.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 5
4.4. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Sender Authentication and Message Forgery . . . . . . . . 6
5.2. Message Observation . . . . . . . . . . . . . . . . . . . 7
5.3. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Unreliable Delivery . . . . . . . . . . . . . . . . . . . 7
5.5. Message Prioritization and Differentiation . . . . . . . . 8
5.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Okmianski Expires March 8, 2008 [Page 2]
Internet-Draft syslog udp transport September 2007
1. Introduction
The informational RFC 3164 [8] describes the syslog protocol as it
was observed in existing implementations. It describes both the
format of syslog messages and a UDP [1] transport. Subsequently, a
standards-track syslog protocol has been defined in the RFC-protocol
[2].
The RFC-protocol specifies a layered architecture that provides for
support of any number of transport layer mappings for transmitting
syslog messages. This document describes the UDP transport mapping
for the syslog protocol.
The transport described in this document can be used for transmitting
syslog messages over both IPv4 [3] and IPv6 [4]. The IPv4 version of
this transport mapping is REQUIRED for all syslog protocol
implementations on devices supporting IPv4. The IPv6 version of this
transport mapping is REQUIRED for all syslog protocol implementations
on IPv6-only devices, and RECOMMENDED for dual-stack devices. These
requirements are mandated for interoperability purposes.
Network administrators and architects should be aware of the
significant reliability and security issues of this transport, which
stem from the use of UDP. They are documented in this specification.
However, this transport is lightweight and is built upon the existing
popular use of UDP for syslog.
2. Conventions Used in This Document
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. Transport Protocol
3.1. One Message Per Datagram
Each syslog UDP datagram MUST contain only one syslog message, which
MAY be complete or truncated. The message MUST be formatted and
truncated according to the RFC-protocol [2]. Additional data MUST
NOT be present in the datagram payload.
3.2. Message Size
This transport mapping supports transmission of syslog messages up to
65535 octets minus the UDP header length. This limit stems from the
Okmianski Expires March 8, 2008 [Page 3]
Internet-Draft syslog udp transport September 2007
maximum supported UDP size of 65535 octets specified in the RFC 768
[1]. For IPv4, the maximum payload size is 65535 octets minus the
UDP header and minus the IP header because IPv4 has a 16-bit length
field that also includes the header length.
IPv4 syslog receivers MUST be able to receive datagrams with message
size up to and including 480 octets. IPv6 syslog receivers MUST be
able to receive datagrams with message size up to and including 1180
octets. All syslog receivers SHOULD be able to receive datagrams
with messages size of up to 2048 octets. The ability to receive
larger messages is encouraged.
The above restrictions and recommendations establish a baseline for
interoperability. The minimum required message size support was
determined based on the minimum MTU size that Internet hosts are
required to support: 576 octets for IPv4 [3] and 1280 octets for IPv6
[4]. Datagrams that conform to these limits have the greatest chance
of being delivered because they do not require fragmentation.
It is RECOMMENDED that syslog senders restrict message sizes such
that IP datagrams do not exceed the smallest MTU of the network in
use. This avoids datagram fragmentation and possible issues
surrounding fragmentation such as incorrect MTU discovery.
Fragmentation can be undesirable because it increases the risk of the
message being lost due to loss of just one datagram fragment. Syslog
has no acknowledgment facility, and therefore there is no effective
way to handle retransmission. This makes it impossible for syslog to
utilize packetization layer path MTU discovery [9]. When network MTU
is not known in advance, the safest assumption is to restrict
messages to 480 octets for IPv4 and 1180 octets for IPv6.
3.3. Source and Target Ports
Syslog receivers MUST support accepting syslog datagrams on the well-
known UDP port 514, but MAY be configurable to listen on a different
port. Syslog senders MUST support sending syslog message datagrams
to the UDP port 514, but MAY be configurable to send messages to a
different port. Syslog senders MAY use any source UDP port for
transmitting messages.
3.4. Source IP Address
The source IP address of the UDP datagrams SHOULD NOT be interpreted
as the identifier for the host that originated the syslog message.
The entity sending the syslog message could be merely a relay. The
syslog message itself contains the identifier of the originator of
the message.
Okmianski Expires March 8, 2008 [Page 4]
Internet-Draft syslog udp transport September 2007
3.5. UDP/IP Structure
Each UDP/IP datagram sent by the transport layer MUST completely
adhere to the structure specified in the UDP RFC 768 [1] and either
IPv4 RFC 791 [3] or IPv6 RFC 2460 [4] depending on which protocol is
used.
3.6. UDP Checksums
Syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders
SHOULD use UDP checksums when sending messages. Note that RFC 2460
[4] mandates the use of UDP checksums when sending UDP datagrams over
IPv6.
Syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog
receivers SHOULD check UDP checksums and they SHOULD accept a syslog
message with a zero checksum. Note that RFC 2460 [4] mandates the
use of checksums for UDP over IPv6.
4. Reliability Considerations
The UDP is an unreliable low-overhead protocol. This section
discusses reliability issues inherent in UDP that implementers and
users should be aware of.
4.1. Lost Datagrams
This transport mapping does not provide any mechanism to detect and
correct loss of datagrams. Datagrams can be lost in transit due to
congestion, corruption, or any other intermittent network problem.
IP fragmentation exacerbates this problem because loss of a single
fragment will result in the entire message being discarded.
4.2. Message Corruption
The UDP/IP datagrams can get corrupted in transit due to software,
hardware, or network errors. This transport mapping specifies use of
UDP checksums to enable corruption detection in addition to checksums
used in IP and Layer 2 protocols. However, checksums do not
guarantee corruption detection, and this transport mapping does not
provide for message acknowledgement or retransmission mechanism.
4.3. Congestion Control
Because syslog can generate unlimited amounts of data, transferring
this data over UDP is generally problematic, because UDP lacks
congestion control mechanisms. Congestion control mechanisms that
Okmianski Expires March 8, 2008 [Page 5]
Internet-Draft syslog udp transport September 2007
respond to congestion by reducing traffic rates and establish a
degree of fairness between flows that share the same path are vital
to the stable operation of the Internet [6]. This is why the syslog
TLS transport [7] is REQUIRED to implement and RECOMMENDED for
general use.
The only environments where the syslog UDP transport MAY be used as
an alternative to the TLS transport are managed networks, where the
network path has been explicitly provisioned for UDP syslog traffic
through traffic engineering mechanisms, such as rate limiting or
capacity reservations. In all other environments, the TLS transport
[7] SHOULD be used.
4.4. Sequenced Delivery
The IP transport used by the UDP does not guarantee that the sequence
of datagram delivery will match the order in which the datagrams were
sent. The time stamp contained within each syslog message can serve
as a rough guide in establishing sequence order, but it will not help
in cases when multiple messages were generated during the same time
slot, the sender cannot generate a time stamp, or messages originated
from different hosts whose clocks are not synchronized. The order of
syslog message arrival via this transport SHOULD NOT be used as an
authoritative guide in establishing an absolute or relative sequence
of events on the syslog sender hosts.
5. Security Considerations
Using this specification on an unsecured network is NOT RECOMMENDED.
Several syslog security considerations are discussed in RFC-protocol
[2]. This section focuses on security considerations specific to the
syslog transport over UDP. Some of the security issues raised in
this section can be mitigated through the use of IPsec as defined in
RFC 4301 [10].
5.1. Sender Authentication and Message Forgery
This transport mapping does not provide for strong sender
authentication. The receiver of the syslog message will not be able
to ascertain that the message was indeed sent from the reported
sender, or whether the packet was sent from another device. This can
also lead to a case of mistaken identity if an inappropriately
configured machine sends syslog messages to a receiver representing
itself as another machine.
This transport mapping does not provide protection against syslog
message forgery. An attacker can transmit syslog messages (either
Okmianski Expires March 8, 2008 [Page 6]
Internet-Draft syslog udp transport September 2007
from the machine from which the messages are purportedly sent or from
any other machine) to a receiver.
In one case, an attacker can hide the true nature of an attack amidst
many other messages. As an example, an attacker can start generating
forged messages indicating a problem on some machine. This can get
the attention of the system administrators, who will spend their time
investigating the alleged problem. During this time, the attacker
could be able to compromise a different machine or a different
process on the same machine.
Additionally, an attacker can generate false syslog messages to give
untrue indications of the status of systems. As an example, an
attacker can stop a critical process on a machine, which could
generate a notification of exit. The attacker can subsequently
generate a forged notification that the process had been restarted.
The system administrators could accept that misinformation and not
verify that the process had indeed not been restarted.
5.2. Message Observation
This transport mapping does not provide confidentiality of the
messages in transit. If syslog messages are in clear text, this is
how they will be transferred. In most cases passing clear-text
human-readable messages is a benefit to the administrators.
Unfortunately, an attacker could also be able to observe the human-
readable contents of syslog messages. The attacker could then use
the knowledge gained from these messages to compromise a machine. It
is RECOMMENDED that no sensitive information be transmitted via this
transport mapping or that transmission of such information be
restricted to properly secured networks.
5.3. Replaying
Message forgery and observation can be combined into a replay attack.
An attacker could record a set of messages that indicate normal
activity of a machine. At a later time, an attacker could remove
that machine from the network and replay the syslog messages with new
time stamps. The administrators could find nothing unusual in the
received messages, and their receipt would falsely indicate normal
activity of the machine.
5.4. Unreliable Delivery
As was previously discussed in the Reliability Considerations
section, the UDP transport is not reliable, and packets containing
syslog message datagrams can be lost in transit without any notice.
There can be security consequences to the loss of one or more syslog
Okmianski Expires March 8, 2008 [Page 7]
Internet-Draft syslog udp transport September 2007
messages. Administrators could be unaware of a developing and
potentially serious problem. Messages could also be intercepted and
discarded by an attacker as a way to hide unauthorized activities.
5.5. Message Prioritization and Differentiation
This transport mapping does not mandate prioritization of syslog
messages on the wire or when processed on the receiving host based on
their severity. Unless some prioritization is implemented by sender,
receiver and/or network, the security implication of such behavior is
that the syslog receiver or network devices could get overwhelmed
with low-severity messages and be forced to discard potentially high-
severity messages.
5.6. Denial of Service
An attacker could overwhelm a receiver by sending more messages to it
than could be handled by the infrastructure or the device itself.
Implementers SHOULD attempt to provide features that minimize this
threat such as optionally restricting reception of messages to a set
of know source IP addresses.
6. IANA Considerations
This transport uses UDP port 514 for syslog, as recorded in the IANA
port-numbers registry.
7. Notice to RFC Editor
This is a notice to the RFC editor. This ID is submitted along with
ID draft-ietf-syslog-protocol and draft-ietf-syslog-transport-tls.
The document cross-reference each other. When RFC numbers are
determined for each of these IDs, please replace all references to
"RFC-protocol" and "RFC-transport-tls" in this document with the RFC
number of draft-ietf-syslog-protocol ID. Also, please update the
date, size and URL fields in the section referencing the new RFC.
Please remove this section after editing.
8. Acknowledgements
The author gratefully acknowledges the contributions of: Chris
Lonvick, Rainer Gerhards, David Harrington, Andrew Ross, Albert
Mietus, Bernie Volz, Mickael Graham, Greg Morris, Alexandra Fedorova,
Devin Kowatch, Richard Graveman, and all others who have commented on
the various versions of this proposal.
Okmianski Expires March 8, 2008 [Page 8]
Internet-Draft syslog udp transport September 2007
9. References
9.1. Normative References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[2] Gerhards, R., "The syslog Protocol", RFC RFC-protocol,
January 2007.
[3] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[7] Miao, F. and Y. Ma, "TLS Transport Mapping for Syslog",
RFC RFC-transport-tls, May 2007.
9.2. Informative References
[8] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[10] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
Author's Address
Anton Okmianski
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719-2205
USA
Phone: +1-978-936-1612
Email: aokmians@cisco.com
Okmianski Expires March 8, 2008 [Page 9]
Internet-Draft syslog udp transport September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Okmianski Expires March 8, 2008 [Page 10]