From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6587.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc6587.txt (limited to 'doc/rfc/rfc6587.txt') 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), + . + + + + + + + + + +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] + -- cgit v1.2.3