[Docs] [txt|pdf] [Tracker] [WG] [Email] [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.
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]


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