GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6587

Internet Engineering Task Force (IETF) R. Gerhards Request for Comments: 6587 Adiscon GmbH Category: Historic C. Lonvick ISSN: 2070-1721 Cisco Systems, Inc.

                                                            April 2012
              Transmission of Syslog Messages over TCP

Abstract

 There have been many implementations and deployments of legacy syslog
 over TCP for many years.  That protocol has evolved without being
 standardized and has proven to be quite interoperable in practice.
 This memo describes how TCP has been used as a transport for syslog
 messages.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for the historical record.
 This document defines a Historic Document for the Internet community.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6587.

IESG Note

 The IESG does not recommend implementing or deploying syslog over
 plain tcp, which is described in this document, because it lacks the
 ability to enable strong security [RFC3365].
 Implementation of the TLS transport [RFC5425] is recommended so that
 appropriate security features are available to operators who want to
 deploy secure syslog.  Similarly, those security features can be
 turned off for those who do not want them.

Gerhards & Lonvick Historic [Page 1] RFC 6587 Transmission of Syslog Messages over TCP April 2012

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
 2. Conventions Used in This Document ...............................5
 3. Message Transmission ............................................5
    3.1. Character Encoding Scheme ..................................5
    3.2. Session ....................................................6
    3.3. Session Initiation .........................................6
    3.4. Message Transfer ...........................................6
         3.4.1. Octet Counting ......................................7
         3.4.2. Non-Transparent-Framing .............................7
         3.4.3. Method Change .......................................8
    3.5. Session Closure ............................................8
 4. Applicability Statement .........................................8
 5. Security Considerations .........................................9
 6. Acknowledgments .................................................9
 7. References .....................................................10
    7.1. Normative References ......................................10
    7.2. Informative References ....................................10

Gerhards & Lonvick Historic [Page 2] RFC 6587 Transmission of Syslog Messages over TCP April 2012

1. Introduction

 The Standards-Track documents in the syslog series recommend using
 the syslog protocol [RFC5424] with the TLS transport [RFC5425] for
 all event messages.  The authors of this document wholeheartedly
 support that position and only offer this document to describe what
 has been observed with legacy syslog over TCP, which appears to still
 be widely used.
 Two primary format options have been observed with legacy syslog
 being transported over TCP.  These have been called "non-transparent-
 framing" and "octet-counting".  The non-transparent-framing mechanism
 has some inherent problems.
 Diagram 1 shows how all of these syslog transports relate to each
 other.  In this diagram, three originators are seen, labeled A, B,
 and C, along with one collector.  Originator A is using the TCP
 transport that is described in this document.  Originator B is using
 the UDP transport, which is described in [RFC5426].  Originator C is
 using the TLS transport, which is described in [RFC5425].  The
 collector is shown with the capability to accept all three
 transports.

Gerhards & Lonvick Historic [Page 3] RFC 6587 Transmission of Syslog Messages over TCP April 2012

  +---------------------+
  | Originator A        |
  |---------------------|
  |  syslog application |
  |                     |
  |---------------------|
  |  syslog transport   |
  |        TCP          |
  |---------------------|
            v
            |
           /                            +---------------------+
          /                             | Originator B        |
         /                              |---------------------|
        /   +----------------------+    |  syslog application |
       /    | Collector            |    |                     |
      |     |----------------------|    |---------------------|
      |     |  syslog application  |    |  syslog transport   |
      |     |                      |    |        UDP          |
      |     |----------------------|    |---------------------|
      |     |  syslog transport    |              v
      |     |  TCP |  TLS  |  UDP  |              |
      |     |----------------------|              |
      |         ^      ^       ^                  |
      |         |      |       |                  |
      \         /      |       \                  /
       ---------       |        ------------------
                       |
                       |
                       |     +---------------------+
                       |     | Originator C        |
                       |     |---------------------|
                       |     |  syslog application |
                       |     |                     |
                       |     |---------------------|
                       |     |  syslog transport   |
                       |     |        TLS          |
                       |     |---------------------|
                       |               v
                       \               /
                        ---------------
              Diagram 1.  Syslog Layers

Gerhards & Lonvick Historic [Page 4] RFC 6587 Transmission of Syslog Messages over TCP April 2012

2. Conventions Used in This Document

 The terminology defined in Section 3 of [RFC5424] is used throughout
 this specification.  The reader should be familiar with that to
 follow this discussion.
 This document also references devices that use the syslog message
 format as described in [RFC3164].  Devices that continue to use that
 message format (regardless of transport) will be described as "legacy
 syslog devices".  Similarly, devices that use the message format as
 described in [RFC5424] will be described as "standardized syslog
 devices".

3. Message Transmission

 Syslog is simplex in nature.  It has been observed that
 implementations of syslog over TCP also do not use any back-channel
 mechanism to convey information to the transport sender and,
 consequently, do not use any application-level acknowledgement for
 syslog signaling from receiver to sender.  Message receipt
 acknowledgement, reliability, and flow control are provided by the
 capabilities of TCP.

3.1. Character Encoding Scheme

 Syslog over TCP messages contain no indication of the coded character
 set (e.g., [US-ASCII] or [UNICODE] ) or character encoding scheme
 (e.g., so-called "7-bit ASCII" or UTF-8 [RFC3629]) in use.  In these
 messages, the predominant approach has been to include characters
 only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using
 the "Network Virtual Terminal" (NVT) encoding [RFC5198].
 The message header usually contains characters only from the ASCII
 repertoire, in the NVT encoding.  This has been observed even in
 cases where a different encoding (e.g., UTF-8) has been used for the
 MSG part.  However, characters outside the ASCII range have been seen
 inside the header.  In that case, some syslog applications have been
 known to experience problems processing those messages.
 In some cases, it has been observed that characters outside of the
 ASCII range are often being transformed by receivers in an effort to
 "escape control characters".  Some receiver implementations simply
 drop those characters.  This is considered to be a poor practice, as
 it causes problems with coded character sets other than ASCII and
 character encodings other than NVT, most notably the UTF-8 encoding
 of Unicode.

Gerhards & Lonvick Historic [Page 5] RFC 6587 Transmission of Syslog Messages over TCP April 2012

 It has also been observed that relays will forward messages using the
 character encoding schemes of messages they receive.  In the case
 where two different senders are using different character encoding
 schemes, the relay will forward each message to a collector in that
 character encoding.  The collector of these messages will have to be
 prepared to receive messages from the same relay with different
 encodings.

3.2. Session

 Like most other protocols, the syslog transport sender is the TCP
 host that initiates the TCP session.  After initiation, messages are
 sent from the transport sender to the transport receiver.  No
 application-level data is transmitted from the transport receiver to
 the transport sender.  The roles of transport sender and receiver
 seem to be fixed once the session is established.
 When it has been observed, if an error occurs that cannot be
 corrected by TCP, the host detecting the error gracefully closes the
 TCP session.  There have been no application-level messages seen that
 were sent to notify the other host about the state of the host syslog
 application.

3.3. Session Initiation

 The TCP host acting as a syslog transport receiver listens to a TCP
 port.  The TCP transport sender initiates a TCP session to the syslog
 transport receiver as specified in [RFC0793].
 This protocol has no standardized port assignment.  In practice,
 network administrators generally choose something that they feel will
 not conflict with anything else active in their networks.  This has
 most often been either TCP/514, which is actually allocated to
 another protocol, or some variant of adding 514 to a multiple of
 1000.  Please see Section 4 for more information.

3.4. Message Transfer

 Syslog over TCP has been around for a number of years.  Just like
 legacy syslog over UDP, different implementations exist.  The older
 method of non-transparent-framing has problems.  The newer method of
 octet-counting is reliable and has not been seen to cause problems
 noted with the non-transparent-framing method.
 In both of these methods, during the message transfer phase, the
 syslog transport sender sends a stream of messages to the transport
 receiver.  These are sent in sequence and one message is encapsulated

Gerhards & Lonvick Historic [Page 6] RFC 6587 Transmission of Syslog Messages over TCP April 2012

 inside each TCP frame.  Either of the TCP hosts may initiate session
 closure at any time as specified in Section 3.5 of [RFC0793].  In
 practice, this is often seen after a prolonged period of inactivity.

3.4.1. Octet Counting

 This framing allows for the transmission of all characters inside a
 syslog message and is similar to the method used in [RFC5425].  A
 transport receiver uses the defined message length to delimit a
 syslog message.  As noted in [RFC3164], the upper limit for a legacy
 syslog message length is 1024 octets.  That length has been expanded
 for standardized syslog.
 It can be assumed that octet-counting framing is used if a syslog
 frame starts with a digit.
 All syslog messages can be considered to be TCP "data" as per the
 Transmission Control Protocol [RFC0793].  The syslog message stream
 has the following ABNF [RFC5234] definition:
     TCP-DATA = *SYSLOG-FRAME
     SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG   ; Octet-counting
                                            ; method
     MSG-LEN = NONZERO-DIGIT *DIGIT
     NONZERO-DIGIT = %d49-57
     SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may
                also be considered to be the payload in [RFC3164]
 MSG-LEN is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME.

3.4.2. Non-Transparent-Framing

 The non-transparent-framing method inserts a syslog message into a
 frame and terminates it with a TRAILER character.  The TRAILER has
 usually been a single character and most often is ASCII LF (%d10).
 However, other characters have also been seen, with ASCII NUL (%d00)
 being a prominent example.  Some devices have also been seen to emit
 a two-character TRAILER, which is usually CR and LF.
 The problem with non-transparent-framing comes from the use of a
 TRAILER character.  In that, the traditional TRAILER character is not
 escaped within the message, which causes problems for the receiver.

Gerhards & Lonvick Historic [Page 7] RFC 6587 Transmission of Syslog Messages over TCP April 2012

 For example, a message in the style of [RFC3164] containing one or
 more LF characters may be misinterpreted as multiple messages by the
 receiving syslog application.
 The ABNF for this is shown here:
     TCP-DATA = *SYSLOG-FRAME
     SYSLOG-FRAME = SYSLOG-MSG TRAILER  ; non-transparent-framing
                                        ; method
     TRAILER = LF / APP-DEFINED
     APP-DEFINED = 1*2OCTET
     SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may
                also be considered to be the payload in [RFC3164]
 A transport receiver can assume that non-transparent-framing is used
 if a syslog frame starts with the ASCII character "<" (%d60).

3.4.3. Method Change

 In legacy implementations, it has been observed that the framing may
 change on a frame-by-frame basis.  This is probably not a good idea,
 but it's been seen.

3.5. Session Closure

 The syslog session is closed when one of the TCP hosts decides to do
 so.  It then initiates a local TCP session closure.  Following TCP
 [RFC0793], it doesn't need to notify the remote TCP host of its
 intention to close the session, nor does it accept any messages that
 are still in transit.

4. Applicability Statement

 Again it must be emphasized that the Standards-Track documents in the
 syslog series recommend using the TLS transport [RFC5425] to
 transport syslog messages.  This document does not recommend that new
 implementations or deployments use syslog over TCP except for the
 explicit purpose of interoperating with existing deployments.
 One of the major problems with interoperability with this protocol is
 that there is no consistent TCP port assigned.  Most of the
 successful implementations have made the selection of a port a user-
 configurable option.  The most frequently observed port for this has
 been TCP/514, which is actually assigned to the Shell protocol.

Gerhards & Lonvick Historic [Page 8] RFC 6587 Transmission of Syslog Messages over TCP April 2012

 Operators must carefully select which port to use in their deployment
 and be prepared to encounter different default port assignments in
 implementations.
 There are several advantages to using TCP: flow control, error
 recovery, and reliability, to name a few.  These reasons, and the
 ease of programming, have led people to use this transmission
 protocol to transmit syslog.
 One potential disadvantage is the buffering mechanism used by TCP.
 Ordinarily, TCP decides when enough data has been received from the
 application to form a segment for transmission.  This may be adjusted
 through timers; but still, some application data may wait in a buffer
 for a relatively long time.  Syslog data is not normally time-
 sensitive, but if this delay is a concern, the syslog transport
 sender may utilize the PUSH Flag as described in [RFC0793] to have
 the sending TCP immediately send all buffered data.

5. Security Considerations

 This protocol makes no meaningful provisions for security.  It lacks
 authentication, integrity checking, and privacy.  It makes no
 provision for flow control or end-to-end confirmation of receipt,
 relying instead on the underlying TCP implementations to approximate
 these functions.  It should not be used if deployment of [RFC5425] on
 the systems in question is feasible.

6. Acknowledgments

 The authors wish to thank David Harrington, Tom Petch, Richard
 Graveman, and all other people who commented on various versions of
 this proposal.  We would also like to thank Peter Saint-Andre for
 clarifying character encodings.
 The authors would also like to thank Randy Presuhn for being our
 reviewer and document shepherd, and a special thanks to Dan Romascanu
 for his support and guidance.

Gerhards & Lonvick Historic [Page 9] RFC 6587 Transmission of Syslog Messages over TCP April 2012

7. References

7.1. Normative References

 [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
             RFC 793, September 1981.
 [RFC3365]   Schiller, J., "Strong Security Requirements for Internet
             Engineering Task Force Standard Protocols", BCP 61,
             RFC 3365, August 2002.
 [RFC5198]   Klensin, J. and M. Padlipsky, "Unicode Format for Network
             Interchange", RFC 5198, March 2008.
 [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5424]   Gerhards, R., "The Syslog Protocol", RFC 5424,
             March 2009.
 [RFC5425]   Miao, F., Ma, Y., and J. Salowey, "Transport Layer
             Security (TLS) Transport Mapping for Syslog", RFC 5425,
             March 2009.
 [US-ASCII]  ANSI, "Coded Character Set -- 7-bit American Standard
             Code for Information Interchange, ANSI X3.4-1986", 1986.

7.2. Informative References

 [RFC3164]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
             August 2001.
 [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
             10646", STD 63, RFC 3629, November 2003.
 [RFC5426]   Okmianski, A., "Transmission of Syslog Messages over
             UDP", RFC 5426, March 2009.
 [UNICODE]   The Unicode Consortium. The Unicode Standard, Version
             6.0.0, (Mountain View, CA: The Unicode Consortium,
             2011. ISBN 978-1-936213-01-6),
             <http://www.unicode.org/versions/Unicode6.0.0/>.

Gerhards & Lonvick Historic [Page 10] RFC 6587 Transmission of Syslog Messages over TCP April 2012

Authors' Addresses

 Rainer Gerhards
 Adiscon GmbH
 Mozartstrasse 21
 Grossrinderfeld, BW  97950
 Germany
 EMail: rgerhards@adiscon.com
 Chris Lonvick
 Cisco Systems, Inc.
 12515 Research Blvd.
 Austin, TX  78759
 USA
 EMail: clonvick@cisco.com

Gerhards & Lonvick Historic [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6587.txt · Last modified: 2012/04/20 22:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki