[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

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

Network Working Group                                        R. Gerhards
Internet-Draft                                              Adiscon GmbH
Intended status: Informational                                C. Lonvick
Expires: August 3, 2011                               Cisco Systems, Inc
                                                        January 30, 2011


                Transmission of Syslog Messages over TCP
                 draft-gerhards-syslog-plain-tcp-07.txt

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.

   The aim of this specification is to document three things: how to
   transmit standardized syslog over TCP, how TCP has been used as a
   transport for legacy syslog, and how to correlate these usages to
   ensure interoperability.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 3, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Gerhards & Lonvick       Expires August 3, 2011                 [Page 1]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
   3.  Message Transmission . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Session  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Session Initiation . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Message Transfer . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Retaining the Original Message . . . . . . . . . . . . . .  7
     3.5.  Session Closure  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     5.1.  Security Considerations from RFC 5426  . . . . . . . . . .  8
     5.2.  Reliability  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Notes to the RFC Editor and Change Log . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Applicability to Legacy syslog  . . . . . . . . . . . 10
     A.1.  Octet-Counting . . . . . . . . . . . . . . . . . . . . . . 11
     A.2.  Octet-Stuffing . . . . . . . . . . . . . . . . . . . . . . 11
     A.3.  Method Change  . . . . . . . . . . . . . . . . . . . . . . 12
     A.4.  Dealing with legacy syslog senders . . . . . . . . . . . . 12
   Appendix B.  Simplified rules for Senders and Receivers  . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13












Gerhards & Lonvick       Expires August 3, 2011                 [Page 2]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


1.  Introduction

   Historically, the syslog protocol [RFC3164] has been run over UDP.
   This has been replaced with the standardized syslog protocol
   [RFC5424] in which the TLS transport [RFC5425] is required.  Even so,
   there are many instances of syslog running atop TCP [RFC0793].  This
   specification documents how the standardized syslog protocol should
   be run atop TCP.  The appendices give more guidance on
   interoperability with legacy devices.

   Two primary format options have been observed with legacy syslog
   being transported over TCP.  These are called octet-stuffing and
   octet-counting.  The octet-stuffing mechanism has some inherent
   problems and is not recommended for use.  However, since receivers
   should be liberal in what they receive, the description of the octet-
   stuffing mechanism is detailed in the first appendix and implementers
   are encouraged to implement it as an option to ensure
   interoperability.

   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
   which 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       Expires August 3, 2011                 [Page 3]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


    +---------------------+
    | 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       Expires August 3, 2011                 [Page 4]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


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" in this document.  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.  Traditional implementations of syslog
   over TCP also do not use any backchannel mechanism to convey
   information to the transport sender, and consequently do not use any
   application-level acknowledgement for syslog receiver to sender
   signaling.  Message receipt acknowledgement, reliability, and flow
   control are provided by the capabilities of TCP.

3.1.  Session

   A syslog over TCP session is a TCP connection between a syslog
   transport sender and a syslog transport receiver.  The syslog
   transport sender is the TCP host that sends the original SYN.  The
   syslog transport receiver is the device that receives the original
   SYN and responds with a SYN+ACK.  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 are
   fixed once the session is established, and they can not be reversed
   during the session.  However, there can be multiple sessions between
   two TCP hosts, and for each session the role of transport sender and
   transport receiver can be different based upon which device initiates
   the session.

   It is valid (but rare) for no syslog messages to be exchanged during
   a TCP session.

   If an error occurs that cannot be corrected by TCP, the host
   detecting the error will gracefully close the TCP session.  There are
   no application level messages that can be sent to notify the other
   host about the state of the host syslog application.





Gerhards & Lonvick       Expires August 3, 2011                 [Page 5]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


3.2.  Session Initiation

   The TCP host that intends to act as a syslog transport receiver
   listens to TCP port <TBD>.  The TCP host that intends to act as the
   transport sender initiates a TCP session to the syslog transport
   receiver as specified in [RFC0793].

3.3.  Message Transfer

   During the message transfer phase, the syslog transport sender sends
   a stream of messages to the transport receiver.  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.

   Syslog messages are sent in sequence within a TCP transport stream.
   One message is encapsulated inside a frame.  This method is known as
   the octet-counting method.  Another method known as the octet-
   stuffing method is described in the appendix below and it must not be
   used to transport standardized syslog.

   All syslog messages must be sent as TCP "data" as per 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

       SP = %d32

       NONZERO-DIGIT = %d49-57

       DIGIT = %d48 / NONZERO-DIGIT

       SYSLOG-MSG is defined in the syslog protocol [RFC5424]


   MSG-LEN is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME.  A
   transport receiver must use the message length to delimit a syslog
   message.  There is no upper limit for a message length per se.
   However, in order to establish a baseline for interoperability, this
   specification requires that a transport receiver must be able to
   process messages with a length up to and including 2048 octets.
   Transport receivers should be able to process messages with lengths
   up to and including 8192 octets.



Gerhards & Lonvick       Expires August 3, 2011                 [Page 6]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


3.4.  Retaining the Original Message

   In this method, a modification is made to the original message for
   transmission.  This is a temporary transformation performed by the
   transport sender.  According to Section 5 of [RFC5425], this
   temporary transformation must be reversed by the transport protocol
   receiver so that the relay or collector will see an exact copy of the
   message generated by the originator or relay.

   In this octet-counting method, a count and a space character are
   prepended to each message.  This is somewhat similar to the framing
   used in Transport Layer Security (TLS) Transport Mapping for Syslog
   [RFC5425].  The count and space character must be removed by the
   transport receiver after it has validated that the count is correct.

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.  It does not
   notify its remote TCP host of its intention to close the session, nor
   does it accept any messages that are still in transit.


4.  Applicability Statement

   It is still recommended to use the TLS transport [RFC5425] to
   transport syslog messages.  This specification is provided to ensure
   interoperability for transporting syslog over TCP.

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

   Even though it is still recommended to use the TLS transport
   [RFC5425] to convey syslog messages, it is expected that people will
   still use the TCP transport.





Gerhards & Lonvick       Expires August 3, 2011                 [Page 7]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


5.  Security Considerations

   Using this specification on an unsecured network is not recommended.
   Several syslog security considerations are discussed in [RFC5424].
   This section focuses on security considerations specific to the
   syslog transport over TCP.  Some of the security issues raised in
   this section can be mitigated through the use of TLS as defined in
   [RFC5425]

5.1.  Security Considerations from RFC 5426

   In many security related respects, the transmission of syslog
   messages over TCP is very similar to the transmission of syslog
   messages over UDP as defined in [RFC5426].  The reader of this
   document is encouraged to be familiar with the following security
   threats that are described in that RFC.
   o  Sender Authentication and Message Forgery
   o  Message Observation
   o  Replaying
   o  Message Priorization and Differentiation
   o  Denial of Service

5.2.  Reliability

   It should be noted that the syslog transport specified in this
   document does not use application-layer acknowledgments.  TCP uses
   retransmissions to provide protection against some forms of data
   loss.  However, if the TCP connection is broken for some reason (or
   closed by the transport receiver), the syslog transport sender cannot
   always know what messages were successfully delivered to the syslog
   application at the other end.

5.3.  Transport Layer Security

   Implementors should be aware of vulnerabilities in the transport
   layer that they choose.  In some cases, these vulnerabilities will be
   in the implementation, such as in the case of the UDP checksum error
   [RFC1122].  In other cases, the vulnerability will be in the
   specification, such as in the case of the SSL/TLS renegotiation as
   described in [RFC5746].

   Specific to this transport, implementers may wish to review any known
   vulnerabilities of TCP prior to writing code.


6.  IANA Considerations

   IANA is requested to provide a TCP port for this protocol.



Gerhards & Lonvick       Expires August 3, 2011                 [Page 8]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


   After that port has been assigned, this section will be revised to
   list that port.


7.  Acknowledgments

   The authors wish to thank David Harrington, Tom Petch, and all other
   people who commented on various versions of this proposal.


8.  Notes to the RFC Editor and Change Log

   These are notes to the RFC editor.  Please delete this section after
   the notes have been followed.

   Please replace the instances of <TBD> the port number assigned by
   IANA.

   Version -07 was submitted in January, 2011.  This clarified what was
   really expected from what was optional.  Appendix B was added for
   further clarification.  Additionally, the security Considerations
   section was edited to include a discussion about transport layer
   issues.

   Version -06 was submitted in October, 2010.  The 2119 language was
   removed.  Also, we compared notes and couldn't find any
   implementations that stacked multiple messages in a frame in the
   octet-counting method.  That paragraph was removed.

   Version -05 was submitted in September, 2010 to address some items
   that David Harrington noted as he is becoming the document shepherd.

   Version -04 was submitted in April, 2010 to clean up some items.

   Version -03 was submitted in April, 2010 based upon further review
   comments from Tom Petch.

   Version -02 was submitted in March, 2010 based upon review comments
   from Tom Petch.

   Version -01 was submitted based upon review comments from David
   Harrington.

   Version -00 was created in November, 2009.


9.  References




Gerhards & Lonvick       Expires August 3, 2011                 [Page 9]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


9.1.  Normative

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

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

   [RFC5426]  Okmianski, A., "Transmission of Syslog Messages over UDP",
              RFC 5426, March 2009.

9.2.  Informative

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

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

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, February 2010.


Appendix A.  Applicability to Legacy syslog

   This appendix is provided for two reasons.
   o  to promote interoperability within the various observed legacy
      implementations
   o  to give advice on how a standard syslog receiver should accept
      messages from legacy syslog senders

   Syslog over TCP has been around for a number of years.  Just like
   legacy syslog over UDP, several different implementations exist.  The
   older method of octet-stuffing has problems so is not recommended,
   but should be implemented to ensure interoperability with older
   clients or servers that may only use this method.  The newer method
   of octet-counting is reliable and, as is consistent with this
   specification, should be implemented.  When implementers do implement
   both methods, it is recommended that the default method be octet-
   counting.




Gerhards & Lonvick       Expires August 3, 2011                [Page 10]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


   The ABNF for this is shown here.

       TCP-DATA = *SYSLOG-FRAME

       SYSLOG-FRAME = MSG-LEN SP SYSLOG-3164   ; Octet-counting method
       SYSLOG-FRAME =/ SYSLOG-3164 TRAILER     ; Octet-stuffing method

       MSG-LEN = NONZERO-DIGIT *DIGIT

       SP = %d32

       NONZERO-DIGIT = %d49-57

       DIGIT = %d48 / NONZERO-DIGIT

       TRAILER = LF | APP-DEFINED

       LF = %d10

       APP-DEFINED = 1*2OCTET

       SYSLOG-3164 is defined in Section 4 of [RFC3164]


A.1.  Octet-Counting

   This framing allows for the transmission of all characters inside
   SYSLOG-MSG and is similar to the framing used in [RFC5425].  MSG-LEN
   is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME.  A
   transport receiver must use the message length to delimit a syslog
   message.  The upper limit for a legacy syslog message length is 1024
   octets.

   A transport receiver must assume that octet-counting framing is used
   if a syslog frame starts with a digit.

A.2.  Octet-Stuffing

   A transport receiver must assume that octet-stuffing framing is used
   if a syslog frame starts with the USASCII character "<" (%d60).

   In this legacy implementation of octet-stuffing, the TRAILER consists
   of a single character and most often is the USASCII LF (%d10)
   character.  A transport receiver must accept the USASCII LF character
   as a TRAILER.  However, other characters have also been seen
   occasionally, with USASCII NUL (%d00) being a prominent example.
   Some devices also emit a two-character TRAILER, which is usually CR
   and LF.  A transport receiver may be configurable to accept



Gerhards & Lonvick       Expires August 3, 2011                [Page 11]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


   characters other than LF.

   The octet-stuffing method is not recommended.

   The problem with octet-stuffing framing comes from the use of
   [RFC3164] messages.  In that, the traditional trailer character is
   not escaped within SYSLOG-3164 which causes problems for the
   receiver.  For example, a message in the style of [RFC3164]
   containing one or more LF characters may be misinterpreted as
   multiple messages by the transport receiver.  There is no method to
   avoid this problem with the octet-stuffing framing.

A.3.  Method Change

   It has been observed in legacy implementations that the framing may
   change on a frame-by-frame basis.  This behavior is not recommended.
   However, for interoperability, a transport receiver wishing to
   interoperate with these legacy systems should be prepared to accept
   different framing for each frame received.

A.4.  Dealing with legacy syslog senders

   The following are recommendations on how a standardized syslog
   receiver should handle messages received from legacy syslog senders.
   o  The standardized syslog receiver is required to support the octet-
      counting method.
   o  The standardized syslog receiver should support the octet-stuffing
      method.

   When supporting the octet-counting method, the standardized syslog
   receiver may encounter message lengths that are over 1024 octets and
   should not fail because of that.

   When supporting the octet-stuffing method, the standardized syslog
   receiver may encounter different TRAILER characters.  They should be
   configured with a default of LF but should have the ability to be
   configured to accept other characters.  Similarly, they may encounter
   messages with lengths that are greater then 1024 octets and should
   not fail because of that.


Appendix B.  Simplified rules for Senders and Receivers

   Since there may be some confusion about sending and receiving octet-
   stuffing and octet-counting packets, this appendix will attempt to
   clarify the recommendation for senders and receivers.





Gerhards & Lonvick       Expires August 3, 2011                [Page 12]

Internet-Draft  Transmission of Syslog Messages over TCP    January 2011


   o  A standardized syslog transmitter must send messages using the
      octet-counting mechanism.  It will never send messages using the
      octet-stuffing mechanism.
   o  A standardized syslog receiver must be set to receive octet-
      counting packets.  It may also be allowed to receive octet-
      stuffing packets from legacy senders.
   o  A legacy syslog transmitter should only use the octet-counting
      method.  There are, however, still legacy transmitters that send
      octet-stuffing packets.
   o  A legacy syslog receiver must accept octet-counting messages, and
      should be able to accept octet-stuffing messages.  It should be
      noted here that a legacy syslog receiver should be replaced with a
      standardized syslog receiver.


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       Expires August 3, 2011                [Page 13]


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