[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5426

syslog Working Group                                        A. Okmianski
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                       November 21, 2006
Expires: May 25, 2007


                Transmission of syslog messages over UDP
                   draft-ietf-syslog-transport-udp-08

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 May 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 May 25, 2007                  [Page 1]

Internet-Draft            syslog udp transport             November 2006


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  . . . . . . . . . . . . . . . . . . . . .  4
     3.6  UDP Checksums . . . . . . . . . . . . . . . . . . . . . . .  5
   4  Reliability Considerations  . . . . . . . . . . . . . . . . . .  5
     4.1  Lost Datagrams  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2  Message Corruption  . . . . . . . . . . . . . . . . . . . .  5
     4.3  Congestion Control  . . . . . . . . . . . . . . . . . . . .  6
     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 . . . . . . . . . . . . . . . . . . . .  8
     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 . . . . . . . . . . 11




















Okmianski                 Expires May 25, 2007                  [Page 2]

Internet-Draft            syslog udp transport             November 2006


1  Introduction

   The informational RFC 3164 [6] 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, the
   syslog protocol has been formally 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.  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 in size.  This limit stems from the maximum supported
   UDP payload of 65535 octets specified in the RFC 768 [1].



Okmianski                 Expires May 25, 2007                  [Page 3]

Internet-Draft            syslog udp transport             November 2006


   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 at least 2048 octets.

   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 fall within 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.  When
   network MTU is not known in advance and cannot be reliably determined
   using path MTU discovery [7], 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.

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.





Okmianski                 Expires May 25, 2007                  [Page 4]

Internet-Draft            syslog udp transport             November 2006


3.6  UDP Checksums

   Use of UDP checksums was defined as OPTIONAL in RFC 768 [1].  IPv6
   has subsequently made UDP checksums REQUIRED in RFC 2460 [4].

   It is RECOMMENDED that syslog senders use valid UDP checksums when
   sending messages over IPv4 and IPv6.

   It is RECOMMENDED that syslog receivers check the checksums whenever
   they are present (i.e. the UDP header checksum field value is not 0)
   and discard messages with incorrect checksums.  Note that this is
   typically accomplished by the UDP layer implementation, and some UDP
   implementations allow for checksum validation to be enabled or
   disabled.


4  Reliability Considerations

   The UDP is an unreliable low-overhead protocol.  This section
   discusses reliability issues inherent in UDP that implementers and
   users MUST 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.

   In some circumstances the sender can receive an ICMP error message or
   other indication of a transmission problem.  If the sender receives a
   reasonable indication that a datagram has been lost, it MAY
   retransmit the datagram.

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 retransmission when a corrupt message is
   detected.

   A special case of corruption is corruption introduced by the UDP
   implementation itself.  For example, several earlier UDP
   implementations defaulted to a buffer size of less than 65535 octets



Okmianski                 Expires May 25, 2007                  [Page 5]

Internet-Draft            syslog udp transport             November 2006


   and truncated larger payloads upon receipt [8].  By following the
   message size recommendations specified in this document, application
   developers can significantly reduce the risk of this type of error.

4.3  Congestion Control

   The UDP does not provide for congestion control.  Any network host or
   router can discard UDP packets when it is overloaded, and can
   optionally provide an ICMP error to indicate this.  One or multiple
   syslog senders can maliciously or inadvertently overload the receiver
   or the network infrastructure and cause loss of syslog messages.

   If the potentially unrestricted use of syslog data being transferred
   over UDP in a particular deployment can saturate the link, then the
   network path should be provisioned so the offered load (including
   syslog packets) does not exceed the path capacity.  Otherwise, some
   of the syslog packets could be lost, or cause the loss of other UDP
   packets.

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.  If present,
   Structured Data element 'sequenceId' contained within syslog messages
   MAY help in establishing the sequence of messages from a single
   sender.  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

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

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



Okmianski                 Expires May 25, 2007                  [Page 6]

Internet-Draft            syslog udp transport             November 2006


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



Okmianski                 Expires May 25, 2007                  [Page 7]

Internet-Draft            syslog udp transport             November 2006


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

   IANA MUST reserve UDP port 514 for this transport.


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 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.  Also, please update the date in the
   section referencing the new RFC.  Please remove this section after
   editing.


8  Acknowledgements

   The author gratefully acknowledges the contributions of: Chris



Okmianski                 Expires May 25, 2007                  [Page 8]

Internet-Draft            syslog udp transport             November 2006


   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.


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.

9.2.  Informative References

   [6]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.

   [7]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
        November 1990.

   [8]  Stevens, W., "TCP/IP Illustrated Volume 1. The Protocols.",
        January 1994.

   [9]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.















Okmianski                 Expires May 25, 2007                  [Page 9]

Internet-Draft            syslog udp transport             November 2006


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 May 25, 2007                 [Page 10]

Internet-Draft            syslog udp transport             November 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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 May 25, 2007                 [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/