Network Working Group R. Gerhards Internet-Draft Adiscon GmbH Intended status: Informational C. Lonvick Expires: April 3, 2011 Cisco Systems, Inc September 30, 2010 Transmission of Syslog Messages over TCP draft-gerhards-syslog-plain-tcp-05.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. 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 April 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Gerhards & Lonvick Expires April 3, 2011 [Page 1] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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. Sender Authentication and Message Forgery . . . . . . . . 8 5.2. Message Observation . . . . . . . . . . . . . . . . . . . 8 5.3. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Message Prioritization and Differentiation . . . . . . . . 9 5.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 5.6. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Notes to the RFC Editor and Change Log . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Applicability to Legacy syslog . . . . . . . . . . . 11 A.1. Octet-Counting . . . . . . . . . . . . . . . . . . . . . . 12 A.2. Octet-Stuffing . . . . . . . . . . . . . . . . . . . . . . 13 A.3. Method Change . . . . . . . . . . . . . . . . . . . . . . 13 A.4. Dealing with legacy syslog senders . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Gerhards & Lonvick Expires April 3, 2011 [Page 2] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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 [RFC5426] 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. Two primary format options have been observed with legacy syslog being transported over TCP. These are called octet-stuffing and octet-counting. This specification includes descriptions of both format options in an attempt to ensure that standardized syslog transport receivers can receive and properly interpret messages sent from legacy syslog senders. 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 April 3, 2011 [Page 3] Internet-Draft Transmission of Syslog Messages over TCP September 2010 +---------------------+ | 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 April 3, 2011 [Page 4] Internet-Draft Transmission of Syslog Messages over TCP September 2010 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 Gerhards & Lonvick Expires April 3, 2011 [Page 5] Internet-Draft Transmission of Syslog Messages over TCP September 2010 no application level messages that can be 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 . 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 time 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 Gerhards & Lonvick Expires April 3, 2011 [Page 6] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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. 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 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 Gerhards & Lonvick Expires April 3, 2011 [Page 7] Internet-Draft Transmission of Syslog Messages over TCP September 2010 [RFC5424] to convey syslog messages, it is expected that people will still use the TCP transport. 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. Sender Authentication and Message Forgery This transport mapping does not provide for strong transport sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or whether the packet was sent from another device. This can also lead to a case of mistaken identity if an inappropriately configured machine sends syslog messages representing itself as another machine. This transport mapping does not provide protection against syslog message forgery. An attacker can transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver. In one case, an attacker can hide the true nature of an attack amidst many other messages. As an example, an attacker can start generating forged messages indicating a problem on some machine. This can get the attention of the system administrators, who will spend their time investigating the alleged problem. During this time, the attacker could be able to compromise a different machine or a different process on the same machine. Additionally, an attacker can generate false syslog messages to give untrue indications of the status of systems. As an example, an attacker can stop a critical process on a machine, which could generate a notification of exit. The attacker can subsequently generate a forged notification that the process had been restarted. The system administrators could accept that misinformation and not verify that the process had indeed not been restarted. 5.2. Message Observation This transport mapping does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is Gerhards & Lonvick Expires April 3, 2011 [Page 8] Internet-Draft Transmission of Syslog Messages over TCP September 2010 how they will be transferred. In most cases, passing clear-text, human-readable messages is a benefit to the administrators. Unfortunately, an attacker could also be able to observe the human- readable contents of syslog messages. The attacker could then use the knowledge gained from these messages to compromise a machine. It is RECOMMENDED that no sensitive information be transmitted via this transport mapping or that transmission of such information be restricted to properly secured networks. 5.3. Replaying Message forgery and observation can be combined into a replay attack. An attacker could record a set of messages that indicate normal activity of a machine. At a later time, an attacker could remove that machine from the network and replay the syslog messages with new time stamps. The administrators could find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine. 5.4. Message Prioritization and Differentiation This transport mapping does not mandate prioritization of syslog messages either on the wire or when processed on the receiving TCP host based on their severity. Unless some prioritization is implemented by sender, receiver, and/or network, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages. 5.5. Denial of Service An attacker could overwhelm a receiver by sending more messages to it than could be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat, such as optionally restricting reception of messages to a set of known source IP addresses. 5.6. 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. Gerhards & Lonvick Expires April 3, 2011 [Page 9] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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, 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 the port number assigned by IANA. 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Gerhards & Lonvick Expires April 3, 2011 [Page 10] Internet-Draft Transmission of Syslog Messages over TCP September 2010 [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 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 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. The ABNF for this is shown here. Gerhards & Lonvick Expires April 3, 2011 [Page 11] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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. Some transport senders have been seen to use this framing to stack multiple messages within a single TCP frame by using a USASCII LF (%d10) character to separate them. As an example, two messages may be placed within a single frame with a LF character between them. This behavior is NOT RECOMMENDED although it has been observed. Since it cannot be known in advance if the legacy transport sender is going to send multiple messages within single frames, it MUST be assumed that they WILL NOT, and that each frame using this method contains only one syslog message. Implementers MAY attempt to address this by looking for TRAILER characters within each frame to try to separate multiple messages. However, this may lead to more problems than it resolves. A transport receiver MUST assume that octet-counting framing is used if a syslog frame starts with a digit. Gerhards & Lonvick Expires April 3, 2011 [Page 12] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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 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 Gerhards & Lonvick Expires April 3, 2011 [Page 13] Internet-Draft Transmission of Syslog Messages over TCP September 2010 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. 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 April 3, 2011 [Page 14]