Network Working Group R. Gerhards
Internet-Draft Adiscon GmbH
Intended status: Informational C. Lonvick
Expires: January 27, 2012 Cisco Systems, Inc
July 26, 2011
Transmission of Syslog Messages over TCP
draft-gerhards-syslog-plain-tcp-09.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 explain how TCP has been used as
a transport for syslog messages.
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 January 27, 2012.
Copyright Notice
Copyright (c) 2011 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
Gerhards & Lonvick Expires January 27, 2012 [Page 1]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
(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 . . . . . . . . . . . . . . . . . . . . 5
3.3. Message Transfer . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Octet Counting . . . . . . . . . . . . . . . . . . . . 6
3.3.2. Octet Stuffing . . . . . . . . . . . . . . . . . . . . 7
3.3.3. Method Change . . . . . . . . . . . . . . . . . . . . 7
3.4. Session Closure . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. Notes to the RFC Editor and Change Log . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Gerhards & Lonvick Expires January 27, 2012 [Page 2]
Internet-Draft Transmission of Syslog Messages over TCP July 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].
Two primary format options have been observed with legacy syslog
being transported over TCP. These have been called octet-stuffing
and octet-counting. The octet-stuffing 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
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 January 27, 2012 [Page 3]
Internet-Draft Transmission of Syslog Messages over TCP July 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 January 27, 2012 [Page 4]
Internet-Draft Transmission of Syslog Messages over TCP July 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". 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 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 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.
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.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].
Gerhards & Lonvick Expires January 27, 2012 [Page 5]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
3.3. 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 octet-stuffing has problems. The newer method of octet-
counting is reliable and is usually preferred.
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
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.3.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 assume 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
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] 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.
Gerhards & Lonvick Expires January 27, 2012 [Page 6]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
3.3.2. Octet Stuffing
The octet stuffing 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 USASCII LF (%d10). However,
other characters have also been seen, with USASCII 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 octet-stuffing 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.
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 ; Octet-stuffing method
TRAILER = LF | APP-DEFINED
LF = %d10
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 octet-stuffing framing is used
if a syslog frame starts with the USASCII character "<" (%d60).
3.3.3. Method Change
It has been observed in legacy implementations that the framing may
change on a frame-by-frame basis. This is probably not a good idea,
but it's been seen.
3.4. 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.
Gerhards & Lonvick Expires January 27, 2012 [Page 7]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
4. Applicability Statement
As per the standards track documents in the syslog series, it is
recommended to use the TLS transport [RFC5425] to transport syslog
messages. This document is provided to document what has been seen
in hopes that interoperability for transporting syslog over TCP may
be achieved.
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.
5. Security Considerations
Even though it is recommended to use the TLS transport [RFC5425] to
convey syslog messages, it is expected that people will still use the
TCP transport.
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]
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.
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
Gerhards & Lonvick Expires January 27, 2012 [Page 8]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
described in [RFC5746]. Specific to this transport, implementers may
wish to review any known vulnerabilities of TCP prior to writing
code. A good start to this investigation may be found in an article
by Steve Bellovin in the Association for Computing Machinery (ACM)
publication [Bellovin].
6. IANA Considerations
IANA is requested to provide a TCP port for this protocol.
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, Richard
Graveman, 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> with the port number assigned
by IANA.
Version -09 was put together based on IESG member feedback. The
appendixes were removed and things were consolidated to be more
appropriate for an informational document. It was submitted in
August of 2011. Dan Romascanu is actually the IESG member who will
watch this document.
Version -08 included a reference to vulnerabilities of TCP. It was
submitted in February of 2011.
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
Gerhards & Lonvick Expires January 27, 2012 [Page 9]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
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
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
Gerhards & Lonvick Expires January 27, 2012 [Page 10]
Internet-Draft Transmission of Syslog Messages over TCP July 2011
Extension", RFC 5746, February 2010.
[Bellovin]
Bellovin, S., "Security problems in the TCP/IP protocol
suite, ACM SIGCOMM Computer Communication Review, Volume
19 Issue 2", April 1989.
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 January 27, 2012 [Page 11]
