summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6587.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6587.txt')
-rw-r--r--doc/rfc/rfc6587.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6587.txt b/doc/rfc/rfc6587.txt
new file mode 100644
index 0000000..8e4030b
--- /dev/null
+++ b/doc/rfc/rfc6587.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+