Subject: [Syslog-sec] OIF Liaison on syslog-transport-udp

From: Chris Lonvick <[email-masked]>
Date: Tue, 31 May 2005 15:04:29 -0500 (CDT)

Hi,

Here's the markup for the syslog-transport-udp ID from the OIF.

Thanks,
Chris

---

syslog Working Group                                        A. Okmianski
Internet-Draft                                       Cisco Systems, Inc.
Expires: May 10, 2005                                   November 9, 2004

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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes the transport for syslog messages over
   UDP/IPv4 or UDP/IPv6.  Syslog protocol layered architecture provided
*s/Syslog/The syslog/
*s/provided/provides/
   for support of any number of transport mappings.  However, for
   interoperability purposes, syslog protocol implementors are required
   to support this transport protocol.

Okmianski                 Expires May 10, 2005                  [Page 1]

Internet-Draft            syslog udp transport             November 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  One Message Per Datagram . . . . . . . . . . . . . . . . . . .  3
   3.  Message Size . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Source and Target Ports  . . . . . . . . . . . . . . . . . . .  4
   5.  Source IP Address  . . . . . . . . . . . . . . . . . . . . . .  4
   6.  UDP/IP Structure . . . . . . . . . . . . . . . . . . . . . . .  4
   7.  UDP Checksums  . . . . . . . . . . . . . . . . . . . . . . . .  4
   8.  Reliability Considerations . . . . . . . . . . . . . . . . . .  5
     8.1   Lost Datagrams . . . . . . . . . . . . . . . . . . . . . .  5
     8.2   Message Corruption . . . . . . . . . . . . . . . . . . . .  5
     8.3   Congestion Control . . . . . . . . . . . . . . . . . . . .  5
     8.4   Sequenced Delivery . . . . . . . . . . . . . . . . . . . .  6
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
     9.1   Sender Authentication  . . . . . . . . . . . . . . . . . .  6
     9.2   Message Forgery  . . . . . . . . . . . . . . . . . . . . .  6
     9.3   Message Observation  . . . . . . . . . . . . . . . . . . .  7
     9.4   Replaying  . . . . . . . . . . . . . . . . . . . . . . . .  7
     9.5   Unreliable Delivery  . . . . . . . . . . . . . . . . . . .  7
     9.6   Message Prioritization and Differentiation . . . . . . . .  7
     9.7   Denial of Service  . . . . . . . . . . . . . . . . . . . .  8
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  8
   11.   Notice to RFC Editor . . . . . . . . . . . . . . . . . . . .  8
   12.   Working Group  . . . . . . . . . . . . . . . . . . . . . . .  8
   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  8
   14.   References . . . . . . . . . . . . . . . . . . . . . . . . .  9
   14.1  Normative References . . . . . . . . . . . . . . . . . . . .  9
   14.2  Informative References . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
       Intellectual Property and Copyright Statements . . . . . . . . 10

Okmianski                 Expires May 10, 2005                  [Page 2]

Internet-Draft            syslog udp transport             November 2004

1.  Introduction

   The informational RFC 3164[1] has originally described the syslog
*s/has //
   protocol as it was observed in the existing implementations.  It
*s/the //
   described both the format of syslog messages and a UDP[2] transport.
   Subsequently, the syslog protocol has been formally defined in the
   standards track RFC-protocol[3].

   The RFC-protocol specified a layered architecture which provided for
*s/which/that/
   support of any number of transport layer protocols for transmitting
   syslog messages.  This standards track RFC describes the UDP
   transport for the syslog protocol.

   This protocol can be utilized for transmitting syslog messages over
*s/utilized /used/
   both IPv4[4] and IPv6[5].  This transport protocol is REQUIRED for
   all syslog protocol implementations for interoperability purposes.

   Network administrators and architects should be aware of the
   significant reliability and security issues of this protocol, which
   stem from the use of UDP.  They are documented in this specification.
   However, this protocol is lightweight and is built upon the existing
   popular use of UDP for syslog.
*i
*1.1 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[6].  The
   words 'byte' and 'octet' are used interchangeably in this
   specification.

2.  One Message Per Datagram

   Each syslog UDP datagram MUST contain one and only one syslog
   message.  The message MUST be formatted according to the
   RFC-protocol[3].  No additional data MUST be present in the datagram
*s/No a/A/
*s/MUST/MUST NOT/
   payload.

3.  Message Size

   This protocol supports transmission of syslog messages up to 65536
   bytes in size.  This limit stems from the maximum supported UDP
   payload of 65536 kilobytes specified in the RFC 768[2].

   IPv4 syslog receivers MUST be able to receive datagrams with message
   size up to and including 480 bytes.  IPv6 syslog receivers MUST be
   able to receive datagrams with message size up to and including 1180
   bytes.  All syslog receivers SHOULD be able to receive datagrams with
   messages size of at least 2048 bytes.
*s/of at least/up to and including/

Okmianski                 Expires May 10, 2005                  [Page 3]

Internet-Draft            syslog udp transport             November 2004

   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 bytes for IPv4[4] and 1280 bytes for
   IPv6[5].  Datagrams which fall within these limits have the greatest
*s/which/that/
   chance of being delivered because they do no require fragmentation.
*s/no/not/

   It is RECOMMENDED that application developers 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 may 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 [8], the safest assumption is to restrict
   messages to 480 bytes for IPv4 and 1180 bytes for IPv6.

4.  Source and Target Ports

   Syslog receivers MUST support accepting syslog datagrams on a
*s/on a/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.

5.  Source IP Address

   The source IP address of the UDP datagrams SHOULD NOT be interpreted
   as the identifier for the host which originated the syslog message.
*s/which/that/
   The entity sending the syslog message may be merely a relay.  Syslog
*s/Syslog/The syslog/
   message itself contains the identifier of the originator of the
   message.

6.  UDP/IP Structure

   Each UDP/IP datagram sent by the transport layer MUST completely
   adhere to the structure specified in the UDP RFC 768[2] and either
   IPv4 RFC 791[4] or IPv6 RFC 2640[5] depending on which protocol is
   used.

7.  UDP Checksums

   Use of UDP checksums was defined as optional in RFC 768[2].  IPv6 has
   subsequently made UDP checksums required in RFC 2460[5].

   Syslog senders MUST utilize valid UDP checksums when sending messages
*s/utilize/use/
   over IPv6.  Syslog senders SHOULD utilize UDP checksums when sending
*s/utilize/use/

Okmianski                 Expires May 10, 2005                  [Page 4]

Internet-Draft            syslog udp transport             November 2004

   messages over IPv4.

   Syslog receivers MUST check the checksums whenever they are present
   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.

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

8.1  Lost Datagrams

   This transport protocol does not provide any mechanism to detect and
   correct loss of datagrams.  Datagrams may be lost in transit due to
   congestion, corruption or any other intermittent network problem.  IP
*s/corruption/corruption,/
   fragmentation exacerbates this problem because loss of a single
   fragment will result in the entire message being discarded.

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

8.2  Message Corruption

   The UDP/IP datagrams may get corrupted in transit due to software,
   hardware or network errors.  This protocol specifies use of UDP
*s/hardware/hardware,/
   checksums to enable corruption detection in addition to checksums
   utilized in IP and Layer 2 layers.  However, checksums do not
*s/utilized/used/
*s/layers/protocols/
   guarantee corruption detection, and this protocol 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 65536 bytes
   and truncated larger payloads upon reception [9].  By following the
   message size recommendations of this protocol, application developers
   can significantly reduce the risk of this type of error.

8.3  Congestion Control

   The UDP does not provide for congestion control.  Any network host
*s/host/host or router/
   can discard UDP packets when it is overloaded, and it may or may not
   provide an ICMP error to indicate this.  One or multiple syslog

Okmianski                 Expires May 10, 2005                  [Page 5]

Internet-Draft            syslog udp transport             November 2004

   senders can maliciously or inadvertently overload the receiver 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
*s/utilized/used/
   sequence of datagram delivery will match the order in which the
   datagrams were sent.  The time stamp contained within each syslog
   message may 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 or when messages originated from different
*s/ or when/, the sender cannot generate a time stamp, or/
   hosts whose clocks are not synchronized.  The order of syslog message
   arrival via this transport  SHOULD NOT be used as an authoritative
*s/  / /
   guide in establishing an absolute or relative sequence of events on
   the syslog sender hosts.

9.  Security Considerations

   Several syslog security considerations have been discussed in
*s/have been/are/
   RFC-protocol[3].  This section focuses on security considerations
   specific to the syslog transport over UDP.

9.1  Sender Authentication

   This transport protocol 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 if the packet was sent from another device.  This may also
*s/if/whether/
   lead to a case of mistaken identify where a misconfigured machine may
*s/identify/identity/
*s/where/if/
*s/ may//
   send syslog messages to a receiver representing itself as another
*s/send/sends/
   machine.

9.2  Message Forgery

   This transport protocol does not provide protection against syslog
   message forgery.  An attacker may 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 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
*s/administrators/administrators,/
   investigating the alleged problem.  During this time, the attacker
   may be able to compromise a different machine, or a different process
*s/,//
   on the same machine.

   Additionally, an attacker may generate false syslog messages to give

Okmianski                 Expires May 10, 2005                  [Page 6]

Internet-Draft            syslog udp transport             November 2004

   untrue indications of status of systems.  As an example, an attacker
*s/status/the status/
   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.
*s/been/not been/

9.3  Message Observation

   This transport protocol 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 may also be able to observe the
   human-readable contents of syslog messages.  The attacker may then
   use the knowledge gained from these messages to compromise a machine.
   It is RECOMMENDED that no sensitive information be transmitted via
   this transport protocol or that transmission of such information be
   restricted to properly secured networks.

9.4  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, an attacker may remove that
   machine from the network and replay the syslog messages with new time
   stamps.  The administrators may find nothing unusual in the received
   messages and their receipt would falsely indicate normal activity of
*s/messages/messages,/
   the machine.

9.5  Unreliable Delivery

   As was previously discussed in the Reliability Considerations
   section, the UDP transport is not reliable and packets containing
*s/reliable/reliable,/
   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 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.6  Message Prioritization and Differentiation

   This transport protocol does not mandate prioritization 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 receiver or network devices may get overwhelmed with low
*s/low /low-/
   severity messages and be forced to discard potentially high severity
*s/high /high-/
   messages.  High severity messages may contain an indication of
*s/High /High-/

Okmianski                 Expires May 10, 2005                  [Page 7]

Internet-Draft            syslog udp transport             November 2004

   serious security problems, but they will not get a higher priority.

9.7  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 optionally restricting reception of messages to a set
   of know IP addresses.
*s/know/known source/

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

   The working group can be contacted via the mailing list:

       [email-masked]

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

       Chris Lonvick
       Cisco Systems
       Email: [email-masked]

13.  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 and all others who have commented on the various
*s/Kowatch/Kowatch,/
   versions of this proposal.

14.  References

Okmianski                 Expires May 10, 2005                  [Page 8]

Internet-Draft            syslog udp transport             November 2004

14.1  Normative References

   [1]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
*Question: Is this informative?

   [2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [3]  Gerhards, R., "The syslog Protocol", RFC RFC-protocol.

   [4]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [7]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

14.2  Informative References

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

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

Author's Address

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

   Phone: +1-978-936-1612
   EMail: [email-masked]

Okmianski                 Expires May 10, 2005                  [Page 9]

Internet-Draft            syslog udp transport             November 2004

Intellectual Property Statement

   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
   [email-masked].

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Okmianski  
               Expires May 10, 2005                 [Page 10]
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Anton Okmianski (aokmians)" <[email-masked]>
Date: Tue, 31 May 2005 13:30:43 -0700

Chris:

I looked at a few suggested edits.  As best I can tell I have already incorporated all these changes based on the earlier unofficial submission of this feedback by OIF.  These changes went into the draft published to this list on April 21.  

Thanks,
Anton.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Chris Lonvick (clonvick)
> Sent: Tuesday, May 31, 2005 4:04 PM
> To: [email-masked]
> Subject: [Syslog-sec] OIF Liaison on syslog-transport-udp
> 
> Hi,
> 
>    UDP/IPv4 or UDP/IPv6.  Syslog protocol layered 
> architecture provided *s/Syslog/The syslog/ *s/provided/provides/
>    The informational RFC 3164[1] has originally described the 
> syslog *s/has //
>    protocol as it was observed in the existing 
> implementations.  It *s/the //
>    The RFC-protocol specified a layered architecture which 
> provided for *s/which/that/
>    This protocol can be utilized for transmitting syslog 
> messages over *s/utilized /used/
>    RFC-protocol[3].  No additional data MUST be present in 
> the datagram *s/No a/A/ *s/MUST/MUST NOT/
>    payload.
> 
> 3.  Message Size
> 
>    IPv6[5].  Datagrams which fall within these limits have 
> the greatest *s/which/that/
>    Syslog receivers MUST support accepting syslog datagrams 
> on a *s/on a/on the/
>    The entity sending the syslog message may be merely a 
> relay.  Syslog *s/Syslog/The syslog/
>    Syslog senders MUST utilize valid UDP checksums when 
> sending messages *s/utilize/use/
>    over IPv6.  Syslog senders SHOULD utilize UDP checksums 
> when sending *s/utilize/use/
> 
> 
> 
>    congestion, corruption or any other intermittent network 
> problem.  IP *s/corruption/corruption,/
>    hardware or network errors.  This protocol specifies use 
> of UDP *s/hardware/hardware,/
>    utilized in IP and Layer 2 layers.  However, checksums do 
> not *s/utilized/used/ *s/layers/protocols/
>    The UDP does not provide for congestion control.  Any 
> network host *s/host/host or router/
>    The IP transport utilized by the UDP does not guarantee 
> that the *s/utilized/used/
>    during the same time slot or when messages originated from 
> different *s/ or when/, the sender cannot generate a time stamp, or/
>    arrival via this transport  SHOULD NOT be used as an 
> authoritative *s/  / /
>    Several syslog security considerations have been discussed 
> in *s/have been/are/
>    sender, or if the packet was sent from another device.  
> This may also *s/if/whether/
>    lead to a case of mistaken identify where a misconfigured 
> machine may *s/identify/identity/ *s/where/if/ *s/ may//
>    send syslog messages to a receiver representing itself as 
> another *s/send/sends/
>    machine.
> 
> 9.2  Message Forgery
> 
>    the attention of the system administrators who will spend 
> their time *s/administrators/administrators,/
>    may be able to compromise a different machine, or a 
> different process *s/,//
>    on the same machine.
> 
>    untrue indications of status of systems.  As an example, 
> an attacker *s/status/the status/
>    messages and their receipt would falsely indicate normal 
> activity of *s/messages/messages,/
>    the machine.
> 
> 9.5  Unreliable Delivery
> 
>    section, the UDP transport is not reliable and packets 
> containing *s/reliable/reliable,/
>    the syslog receiver or network devices may get overwhelmed 
> with low *s/low /low-/
>    severity messages and be forced to discard potentially 
> high severity *s/high /high-/
>    messages.  High severity messages may contain an 
> indication of *s/High /High-/
> 
> 
> 
>    Devin Kowatch and all others who have commented on the 
> various *s/Kowatch/Kowatch,/