[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.
Expires: October 30, 2004                                       May 2004



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


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 October 30, 2004.


Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract


   This document describes the transport for syslog messages over UDP/
   IPv4 or UDP/IPv6.  While several transport mappings are envisioned
   for the syslog protocol, syslog protocol implementors are required to
   support the transport mapping described in this document.  This
   transport specification overcomes limitations of UDP/IP datagram size
   by introducing support for fragmentation of large messages.










Okmianski               Expires October 30, 2004                [Page 1]

Internet-Draft            syslog udp transport                  May 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Transport Protocol Overview  . . . . . . . . . . . . . . . . .  4
     2.1   Definitions and Architecture . . . . . . . . . . . . . . .  4
     2.2   Required Transport Protocol  . . . . . . . . . . . . . . .  5
     2.3   Encapsulation Layers . . . . . . . . . . . . . . . . . . .  5
   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Basic Header Format  . . . . . . . . . . . . . . . . . . .  6
     3.2   Extended Header Format . . . . . . . . . . . . . . . . . .  7
       3.2.1   Message Identifier . . . . . . . . . . . . . . . . . .  7
       3.2.2   Total Length . . . . . . . . . . . . . . . . . . . . .  8
       3.2.3   Fragment Offset  . . . . . . . . . . . . . . . . . . .  8
       3.2.4   Extended Header Example  . . . . . . . . . . . . . . .  8
     3.3   Payload  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.4   Supported Message Length . . . . . . . . . . . . . . . . .  9
   4.  UDP/IP Layer Considerations  . . . . . . . . . . . . . . . . . 10
     4.1   Target Port  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2   Source Port  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3   Source IP Address  . . . . . . . . . . . . . . . . . . . . 10
     4.4   UDP/IP Headers . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 11
     5.1   Message Fragmentation  . . . . . . . . . . . . . . . . . . 11
     5.2   Message Reassembly . . . . . . . . . . . . . . . . . . . . 12
     5.3   Avoiding Fragmentation . . . . . . . . . . . . . . . . . . 12
   6.  Reliability Considerations . . . . . . . . . . . . . . . . . . 13
     6.1   Lost Datagrams . . . . . . . . . . . . . . . . . . . . . . 13
     6.2   Message Corruption and Checksums . . . . . . . . . . . . . 13
     6.3   Congestion Control . . . . . . . . . . . . . . . . . . . . 13
     6.4   Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 13
     6.5   Sender Authentication  . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     7.1   Message Authenticity . . . . . . . . . . . . . . . . . . . 14
     7.2   Message Forgery  . . . . . . . . . . . . . . . . . . . . . 14
     7.3   Message Observation  . . . . . . . . . . . . . . . . . . . 15
     7.4   Replaying  . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.5   Unreliable Delivery  . . . . . . . . . . . . . . . . . . . 15
     7.6   Message Prioritization and Differentiation . . . . . . . . 15
     7.7   Denial of Service  . . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Notice to RFC Editor . . . . . . . . . . . . . . . . . . . . . 16
   10.   Working Group  . . . . . . . . . . . . . . . . . . . . . . . 16
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 17
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
   A.  Rational For Transport Message Size Restrictions . . . . . . . 18




Okmianski               Expires October 30, 2004                [Page 2]

Internet-Draft            syslog udp transport                  May 2004



       Intellectual Property and Copyright Statements . . . . . . . . 20



















































Okmianski               Expires October 30, 2004                [Page 3]

Internet-Draft            syslog udp transport                  May 2004



1.  Introduction


   The original syslog protocol has been described in informational RFC
   3164[1] as observed in existing implementations.  It describes both
   the semantics of the syslog message format as well as a UDP
   transport.  Subsequently, the syslog protocol has been formally
   defined in a standards track RFC-protocol[2].


   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.  This
   transport protocol is REQUIRED for all syslog protocol
   implementations.


   This transport protocol was designed to work on top of UDP [3] over
   both IPv4 [4] and IPv6 [5].  This protocol overcomes the data size
   restrictions of the UDP protocol by supporting message fragmentation.
   Support for fragmentation is only REQUIRED for implementations
   wishing to support messages which exceed certain size limits outline
   in this specification.


   This protocol has significant reliability and security issues
   stemming from the use of UDP.  They are documented in this
   specification.  This protocol also does not support acknowledgements
   of message receipt by the receiver and does not incorporate any
   reliable retransmission mechanism for lost datagrams.  However, this
   protocol is lightweight and extends on the existing popular use of
   UDP for syslog.  Network administrators and architects should be
   aware of the shortcomings of this protocol and plan accordingly.


   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.  Transport Protocol Overview


2.1  Definitions and Architecture


   The following definitions will be used in this document:
   o  An application that can generate syslog messages will be referred
      to as a "sender";
   o  An application that can receive syslog messages will be referred
      to as a "receiver".


   An application can function in dual capacity.  For example, a syslog




Okmianski               Expires October 30, 2004                [Page 4]

Internet-Draft            syslog udp transport                  May 2004



   relay may receive and forward messages.  A single system can host any
   number of syslog senders.  Only one syslog receiver can be hosted on
   a single system using the standard listening port.


2.2  Required Transport Protocol


   This document describes the UDP transport layer protocol for the
   syslog protocol RFC-protocol[2].  Every syslog sender and receiver
   implementation which adheres to the RFC-protocol[2] MUST fully
   implement the transport protocol specified in this document.  An
   implementation does not have to support both IPv4 and IPv6 if it is
   designed to be used over only one of these protocols.


2.3  Encapsulation Layers


   This syslog transport carries syslog messages as a generic payload
   encapsulated with a syslog transport header, UDP header and an IP
   header.  Below is a summary of syslog UDP/IP packet structure as used
   by this transport protocol:



                +--------------------------------+
                |       IPv4 or IPv6 Header      |
                |        (20 or more bytes)      |
                +--------------------------------+
                |           UDP Header           |
                |           (8 bytes)            |
                +--------------------------------+
                |    Syslog Transport Header     |
                |        (5 or 32 bytes)         |
                +--------------------------------+
                |     Syslog Message Payload     |
                |       (1 to 1191 bytes)        |
                +--------------------------------+


   Some syslog messages may be transmitted using one UDP/IP datagram per
   message.  Syslog protocol [2] allows messages as large as 16777216
   bytes, while UDP/IP datagram cannot exceed a total size of 65526
   bytes [3] and most existing protocols restrict the size of UDP data
   to much less.  In order to support transmitting large messages over
   UDP/IP, this transport protocol supports fragmentation of large
   syslog messages into multiple UDP/IP datagrams for transmission and
   reassembly on the receiving end.


   Each syslog UDP/IP datagram MUST contain one and only one complete
   syslog message or one fragment of a message.  Transmitting multiple
   messages or multiple fragments of different messages in a single UDP
   datagram is not supported by this protocol.




Okmianski               Expires October 30, 2004                [Page 5]

Internet-Draft            syslog udp transport                  May 2004



3.  Message Format


   The syslog transport message consists of a transport header and a
   syslog message payload.  The format of the transport header is
   different for fragmented and non-fragmented messages.  The basic
   transport header format is used for non-fragmented messages and the
   extended transport header format is used for fragmented messages.
   The receiver MUST discard messages with incorrectly formatted
   headers.


   An ASCII-based encoding was chosen for the syslog transport for
   consistency with the RFC-protocol[2].  Syslog transport messages have
   the following format in ABNF[7] notation:



       SyslogTransportMessage = ( BasicHeader / ExtendedHeader )
                                         SP Payload


       BasicHeader     = Version SP "0"
       Version         = %d118 1*3DIGIT   ; "v1" in this version


       ExtendedHeader  = Version SP "1" SP MessageId
                         SP TotalLength SP FragmentOffset


       MessageId       = 1*8DIGIT        ; 0 to 16777215
       TotalLength     = 1*8DIGIT        ; 1 to 16777216
       FragmentOffset  = 1*8DIGIT        ; 0 to 16777215


       Payload         = 1*1191OCTET


       OCTET           = %d00-255
       DIGIT           = %d48-57
       SP              = %d32



3.1  Basic Header Format


   When no fragmentation is used and the entire syslog message is
   transferred as a single UDP/IP datagram, a basic syslog transport
   header MUST be used.  The version for this protocol is "1".  It must
   be followed by one space, a "0" to indicate that this is a basic
   header and a trailing space.  Therefore, the only possible value for
   the basic header in this protocol is as follows:



      "v1 0 "


   Example of a syslog message without the transport header (message is




Okmianski               Expires October 30, 2004                [Page 6]

Internet-Draft            syslog udp transport                  May 2004



   wrapped for display):



      "v1 888 3 2003-10-11T22:14:15.003Z host.domain.com
      dns: configuration error"


   Example of the same message with the transport header (message is
   wrapped for display):



      "v1 0 v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
      dns: configuration error"



3.2  Extended Header Format


   When a syslog message is fragmented by the sender, multiple UDP
   datagrams MUST be used and each datagram MUST contain an extended
   syslog transport header.  The version for this protocol is "1".  The
   version field MUST be followed by a single space and a "1" to
   indicate that this is an extended header.  Thus, an extended header
   MUST always begin with "v1 1 ", but MUST also have additional fields
   which aid in reassembly.


   The MessageId, TotalLength and FragmentOffset fields are used solely
   for fragmentation of long messages and reassembly.  They MUST NOT be
   used for other purposes.


3.2.1  Message Identifier


   The MessageId field (along with the source UDP port and the IP
   address) is used to identify the message such that fragments of a
   single syslog message can be reassembled by the receiver into a
   complete message.  The MessageId field MUST be a numeric value in the
   range of 0 to 16777215.  Leading zeros MUST NOT be present in the
   MessageId field.


   Each syslog sender process MUST choose a random MessageId value
   within the supported range for its first message.  The sender SHOULD
   increment the MessageId by 1 up to 16777215 for each subsequent
   message and then continue at 0.  Incrementing the value each time
   ensures that MessageId is unique and does not repeat over a long
   range of values.  Using random value for the first MessageId helps
   reduce the possibility of potential errors in message reassembly.
   Refer to discussion about message reassembly (Section 5.2) for more
   details.


   All datagrams which represent parts of a given fragmented syslog




Okmianski               Expires October 30, 2004                [Page 7]

Internet-Draft            syslog udp transport                  May 2004



   message MUST have the same MessageId value.


3.2.2  Total Length


   The TotalLength field MUST be a numeric value in the range of 1 to
   16777216.  It MUST indicate the length of a complete syslog message
   in bytes before it was fragmented and before it was encapsulated with
   transport headers.  The same TotalLength field value MUST be present
   in all UDP datagrams which represent fragments of the same syslog
   message.  Leading zeros MUST not be present in the TotalLength field.


   Note that the TotalLength field is used to identify the total length
   of a complete syslog message, which is transmitted using multiple
   fragments and multiple datagram packets.  The fragment length is not
   specified in the transport header because it can be inferred from the
   size of the IP packet containing the UDP datagram.


3.2.3  Fragment Offset


   The FragmentOffset field MUST be a numeric value in the range of 0 to
   16777215.  It MUST indicate the byte offset of the fragment data in
   the complete syslog message.  The offset index starts at 0 for the
   first fragment.  For example, suppose we want to fragment a 700 byte
   syslog message into 480 and 220 byte parts.  Then, the FragmentOffset
   in the first message will be 0 and in the second - 480.  Note that
   fragments don't have to be the same size.  Leading zeros MUST not be
   present in the FragmentOffset field.


3.2.4  Extended Header Example


   The following is an example of a syslog message without the transport
   header (message is wrapped for display):



      "v1 888 4 2003-10-11T22:14:15.003Z host.domain.com
      dns: configuration error"


   Suppose this message had to be fragmented by transport layer into two
   parts at an arbitrary point.  This would result in two separate UDP
   datagrams being sent - one for each fragment.  Below is the content
   of each of the syslog transport UDP messages with syslog transport
   headers but without UDP/IP headers:



      "v1 1 45612221 74 0 v1 888 4 2003-10-11T22:14:15.003Z host.dom"


      "v1 1 45612221 74 42 ain.com dns: configuration error"





Okmianski               Expires October 30, 2004                [Page 8]

Internet-Draft            syslog udp transport                  May 2004



   In the above example, the leading "v1" is the version of the
   transport protocol, "1" indicates that this is an extended header
   (fragmentation in use), "45612221" is the MessageId, "74" is the
   TotalLength of the message, while "0" and "42" are FragmentOffset
   fields.  Everything following the FragmentOffset and a space is the
   Payload of each respective message.


3.3  Payload


   The Payload field of the syslog transport message is an entire syslog
   message or one fragment.  The maximum Payload size depends on the IP
   protocol used and the type header that is used.


      Maximum Payload size:


      With IPv4 and basic header:    507 bytes
      With IPv4 and extended header: 480 bytes


      With IPv6 and basic header:    1191 bytes
      With IPv6 and extended header: 1164 bytes


   The receiver MUST discard messages with Payload sizes exceeding the
   above restrictions.  The Payload size restrictions above effectively
   mean that the largest syslog message that can be sent non-fragmented
   is 507 bytes for transport via IPv4 and 1191 bytes for transport via
   IPv6.


   For a discussion of the rational behind the above size restrictions
   please refer to Appendix A.


3.4  Supported Message Length


   The maximum syslog message length supported by this protocol is the
   maximum value of the TotalLength field, which is 16777216 bytes.
   However, not all deployment scenarios for syslog will be on hosts
   with hardware capable of supporting this maximum length of messages.
   Additionally, extremely large messages may not be needed in many
   environments.  Therefore, implementations are NOT REQUIRED to support
   the maximum message length allowed by this protocol.


   All implementations MUST support sending and receiving syslog
   messages up to and including the size which does not require
   fragmentation (507 bytes for IPv4 and 1191 bytes for IPv6).  This
   size excludes the overhead of the syslog transport and UDP/IP
   headers.  Support for larger messages is encouraged.  Implementors
   SHOULD clearly state the maximum supported message size in
   documentation.





Okmianski               Expires October 30, 2004                [Page 9]

Internet-Draft            syslog udp transport                  May 2004



   The receiver which receives a message greater than it can handle
   SHOULD discard the message.  A diagnostic message MAY be logged by
   the receiver, but care SHOULD be taken not to expose this behavior as
   an additional vulnerability for denial of service attack.


4.  UDP/IP Layer Considerations


4.1  Target Port


   Syslog receivers MUST support accepting syslog message datagrams on
   the well-known UDP port 514.  Syslog senders MUST support sending
   syslog message datagrams to the UDP port 514.


4.2  Source Port


   Syslog senders can use any source UDP port for transmitting messages.
   Senders MAY randomly select a source port, but MUST use the port in
   an exclusive fashion.  No concurrent port reuse on the same host is
   allowed.


   Since source port is used to identify parts of a fragmented message,
   the sender MUST use the same port to send all fragments of a given
   message.  If due to an error or other condition, the sender is unable
   to do that, the sender MAY resend all message fragments and if it
   does so, it MUST use the new port and a new MessageId field value.


4.3  Source IP Address


   The source IP address of the UDP datagrams is one of the data
   elements used to identify parts of a fragmented message.  Therefore,
   a syslog sender MUST attempt to use the same source IP address to
   send all fragments of a given syslog message.  If due to an error,
   reconfiguration or other condition it is unable to do so, the sender
   MAY resend all fragments of the syslog message and, if it does so, it
   MUST use the new source IP address and a new MessageId value.


4.4  UDP/IP Headers


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


   Use of UDP checksums was defined as optional in RFC 768[3].  IPv6 has
   subsequently made UDP checksums required [5].  Syslog senders MUST
   utilize valid UDP checksums when sending messages over IPv6 and
   SHOULD do it when sending over IPv4.  Syslog receivers MUST check the
   checksums whenever they are present and discard messages with




Okmianski               Expires October 30, 2004               [Page 10]

Internet-Draft            syslog udp transport                  May 2004



   incorrect checksums.  Note that this is typically accomplished by the
   UDP layer implementation, and some implementations allow for checksum
   checks to be enabled or disabled.


   Enabling use of checksums serves as an extra measure of corruption
   detection in addition to checksums performed by IP and Layer 2
   protocols such as Ethernet.  None of the above checksums provide a
   complete guarantee of corruption detection.  Utilizing checksums on
   multiple layers reduces the chance of a corruption error not being
   detected.


5.  Fragmentation and Reassembly


5.1  Message Fragmentation


   The syslog transport layer MUST perform fragmentation if the size of
   a given syslog message exceeds the maximum allowed Payload size.
   Fragmentation SHOULD NOT be used if message can fit into the maximum
   allowed Payload size.


   Syslog messages SHOULD be fragmented such that all but last message
   utilize the Payload to its maximum capacity.  For example, when using
   IPv4, a 700 byte syslog message SHOULD be fragmented into 480 and 220
   byte parts because the maximum Payload size with IPv4 and extended
   header is 480 bytes.


   Each message fragment MUST be sent as a separate UDP/IP datagram with
   an extended syslog transport header.  The sender MUST use the same
   MessageId value, TotalLength value, source port and source IP address
   for all fragments of a given message.  These three field together
   uniquely identify fragments belonging to a given message.


   On a system with short-lived sender processes, it may be possible
   that fragments with the same MessageId value, TotalLength value,
   source port and source IP address will get generated in short time
   proximity.  This can be possible because a new process may re-use the
   source port that was freed up by another process that just dies.
   Such behavior could confuse the receiver if the datagrams were
   received out of order or some datagrams got lost.


   In order to reduce the risk of such mistaken identity errors, section
   3.2.1 specified that each process must start with a random value for
   MessageId field.  Given a relatively large range of MessageId values
   and the unlikely event of a coincidence of having the same MessageId
   and TotalLength values combined with re-used source port and UDP
   errors, the window for potential mistaken identity errors during
   message reassembly is very small and tolerable.  The users take a
   greater risk by using this protocol due to general UDP reliability




Okmianski               Expires October 30, 2004               [Page 11]

Internet-Draft            syslog udp transport                  May 2004



   issues discussed later in this specification.


5.2  Message Reassembly


   The reassembly process uses the source IP address from the IP header,
   the source port from the UDP header, the MessageId and TotalLength
   field values to identify fragments of a given message.  It then uses
   data from the TotalLength and FragmentOffset fields to re-assemble
   fragments into a complete message.  If one of the fragments of the
   message is not received, all other fragments of the message SHOULD be
   discarded.


   Typically, an implementation of fragmentation reassembly involves
   allocating a buffer for the message when any fragment with a new
   combination of source IP address, source port, MessageId and
   TotalLength values is received.  A timer is used to expire the
   message reassembly and clean the buffer if all fragments are not
   received within a certain time period.  As each fragment is received,
   it is placed into the buffer at the appropriate offset and a check is
   performed to determine if all fragments have been received using
   additional data structures.


   The receiver SHOULD make the timeout interval used for message
   reassembly configurable for the administrator.  The receiver SHOULD
   also be able to limit the total amount of memory used for buffers
   such that it does not run out of resources under a simple denial of
   service attack involving just one message fragment with a large
   TotalLength field value.  Degrading the service under heavy load or
   attack is better than crashing and potentially making the service
   completely unavailable.


   The receiver MUST validate the FragmentOffset and fragment length
   against the TotalLength of the message to ensure that the fragment
   fits into the buffer.  This would prevent a typical buffer overflow
   exploit by attackers.


5.3  Avoiding Fragmentation


   Fragmentation and reassembly of messages incurs substantial
   processing overhead on both the sender and the receiver hosts.  It
   also increases the risk of lost messages due to loss of just one
   fragment.  It is RECOMMENDED that syslog senders which anticipate
   sending messages over this transport protocol attempt to reduce the
   number of messages which require fragmentation by only sending
   messages which are small enough not to require fragmentation.







Okmianski               Expires October 30, 2004               [Page 12]

Internet-Draft            syslog udp transport                  May 2004



6.  Reliability Considerations


   The UDP is an unreliable low-overhead protocol.  This section
   discusses reliability issues inherent to UDP that implementers and
   users MUST be aware of.


6.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.
   The transport protocol fragmentation and IP fragmentation exacerbate
   the 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 some datagram may have been lost, it MAY
   retransmit previously sent messages by either retransmitting the
   datagram(s) or by transmitting the message with a new MessageId
   value.


6.2  Message Corruption and Checksums


   The UDP/IP datagrams may get corrupted in transit due to software,
   hardware or network errors.  This protocol specifies use of UDP
   checksums to enable corruption detection in addition to checksums
   utilized in IP and Layer 2 layers.  However, checksums do not
   guarantee corruption detection and this protocol does not provide for
   message retransmission when a corrupt message is detected.


6.3  Congestion Control


   The UDP 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 [9].  Any network host can discard UDP packets when
   it is overloaded.  Due to lack of congestion control one or multiple
   syslog senders can maliciously or inadvertently overload the receiver
   or the network infrastructure and cause loss of syslog messages.


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




Okmianski               Expires October 30, 2004               [Page 13]

Internet-Draft            syslog udp transport                  May 2004



   hosts whose clocks are not synchronized.  The order of syslog message
   arrival via the this syslog transport SHOULD NOT be used as an
   authoritative guide in establishing the sequence of events on the
   syslog sender hosts.


6.5  Sender Authentication


   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.


   One possible consequence of this behavior is that a misconfigured
   machine may send syslog messages to a receiver representing itself as
   another machine.  The administrators may not be able to readily
   discern that there are two or more machines representing themselves
   as the same machine.


7.  Security Considerations


   Several syslog security considerations have been discussed in
   RFC-protocol[2] and in the original RFC 3164[1].  This section
   focuses on security considerations specific to the syslog transport
   over UDP.


7.1  Message Authenticity


   This transport protocol does not strongly authenticate the identity
   of the message sender and does not provide any assurance that the
   message was not modified in transit.  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.


7.2  Message Forgery


   Syslog messages can be easily forged.  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
   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.





Okmianski               Expires October 30, 2004               [Page 14]

Internet-Draft            syslog udp transport                  May 2004



   Additionally, an attacker may generate false syslog messages to give
   untrue indications of status of systems.  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.


7.3  Message Observation


   The 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 those messages to compromise a machine
   or do other damage.  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.


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


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


7.6  Message Prioritization and Differentiation


   The transport protocol described in this document does not require
   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 severity messages and be forced to discard




Okmianski               Expires October 30, 2004               [Page 15]

Internet-Draft            syslog udp transport                  May 2004



   potentially high severity messages.  High severity messages may
   contain an indication of serious security problems, but they will not
   get a higher priority.  It is difficult to make sure that high
   severity messages get higher end-to-end delivery priority, especially
   over an unreliable UDP transport which provides no congestion
   control.


7.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 only receiving syslog messages from known IP
   addresses.


8.  IANA Considerations


   IANA must reserve UDP port 514 for this transport.


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


10.  Working Group


   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



11.  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
   versions of this proposal.




Okmianski               Expires October 30, 2004               [Page 16]

Internet-Draft            syslog udp transport                  May 2004



12.  References


12.1  Normative 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]  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]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.


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


12.2  Informative References


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


   [10]  Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.


   [11]  Hedrick, C., "Routing Information Protocol", RFC 1058, June
         1988.


   [12]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.


   [13]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC
         1350, July 1992.


   [14]  Kent, C. and J. Mogul, ""Fragmentation Considered Harmful,"
         Computer Communications Review, vol.17, no.5, pp.390-401",
         August 1987.


   [15]  Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
         the Differentiated Services Field (DS Field) in the IPv4 and




Okmianski               Expires October 30, 2004               [Page 17]

Internet-Draft            syslog udp transport                  May 2004



         IPv6 Headers", RFC 2474, December 1998.



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


Appendix A.  Rational For Transport Message Size Restrictions


   This appendix provides the rational behind the Payload size
   restrictions for this protocol.  The Payload restrictions outlined in
   the specification, ensure that the transport message size does not
   exceed 512 bytes (without UDP/IP headers) for transport via IPv4 and
   does not exceed 1196 bytes for transport via IPv6.  These
   restrictions put an upper boundary on the UDP/IP datagram size for
   this protocol, which accomplishes two goals.


   First, they insure interoperability between various UDP/IP
   implementations.  Even though the maximum IP datagram size is
   specified as 65536 bytes, many UDP/IP implementations have been shown
   not to work with large datagram sizes [9].  Many established
   UDP-based protocols restrict UDP datagram data size to 512 bytes.
   For example, DNS [10] and RIP [11] do that.  The DHCPv4 [12]
   restricts the size to 512 bytes, but allows sides to agree on a
   larger value through the protocol.  The TFTP [13] restricts the UDP
   data size to 518 bytes, which is slightly larger.


   The second reason for datagram size restrictions is that it reduces
   the likelihood of the IP-layer datagram fragmentation.  Syslog
   message can be fragmented on two levels: syslog transport protocol
   and IP layer.  Since fragmentation has significant overhead for
   message reassembly, it is best to avoid double fragmentation.  The
   likelihood of IP fragmentation can be significantly reduced by
   sending IP datagrams in sizes which all hosts must be able to
   process.


   The minimum MTU of a transport protocol determines the minimum size
   of packets that hosts must be able to accept.  For IPv4, the minimum
   MTU is 576 bytes [4] and for IPv6 - 1280 bytes [5].  In both cases,
   the maximum message size fits within the MTU of the transport in all
   cases except for when extremely large IP headers are used.  IPv4




Okmianski               Expires October 30, 2004               [Page 18]

Internet-Draft            syslog udp transport                  May 2004



   header can range from 20 to 60 bytes in length and UDP header is
   fixed at 8 bytes.  Thus, the message size restrictions ensure that in
   all cases except for when the IP header is 56 bytes or greater, the
   size of the packet will be within the size of the transport MTU.


   For IPv6, the specification provides for the same amount of padding
   for UDP/IP headers as was conventionally done for IPv4 in DNS, RIP
   and DHCPv4 with an additional padding of extra 20 bytes to
   accommodate a larger IPv6 header.  This follows the methodology
   suggested in the IPv6 specification for calculating upper-layer
   payload limits [5].


   Path MTU discovery can generally be used to discover the MTU of the
   link.  Unfortunately, using path MTU discovery with UDP is not a
   reliable option because it depends on routers providing ICMP errors
   and hosts doing retransmission, which are not done consistently.
   Implementors MUST follow the size restrictions outlined above and not
   rely on path MTU discovery.


































Okmianski               Expires October 30, 2004               [Page 19]

Internet-Draft            syslog udp transport                  May 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 October 30, 2004               [Page 20]

Internet-Draft            syslog udp transport                  May 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 October 30, 2004               [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/