No home yet R. Gerhards
Internet-Draft Adiscon GmbH
Expires: June 3, 2010 C. Lonvick
Cisco Systems, Inc
November 30, 2009
Transmission of Syslog Messages over TCP
draft-gerhards-syslog-plain-tcp-00.txt
Abstract
This document describes the transport for syslog messages over TCP/
IPv4 or TCP/IPv6. The syslog protocol layered architecture provides
for support of any number of transport mappings. However, for
interoperability purposes, syslog protocol implementers are required
to support this transport mapping.
There have been many implementations and deployments of traditional
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 this has been done for
traditional syslog, and how the new syslog architecture can
interoperate with the traditional deployments.
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.
Gerhards & Lonvick Expires June 3, 2010 [Page 1]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
This Internet-Draft will expire on June 3, 2010.
Copyright Notice
Copyright (c) 2009 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 BSD License.
Gerhards & Lonvick Expires June 3, 2010 [Page 2]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Message Transmission . . . . . . . . . . . . . . . . . . . . . 3
3.1. Session . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Session Initiation . . . . . . . . . . . . . . . . . . . . 5
3.3. Message Transfer . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Octet-Stuffing . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Octet-Counting . . . . . . . . . . . . . . . . . . . . 7
3.4. Message Content . . . . . . . . . . . . . . . . . . . . . 7
3.5. Session Closure . . . . . . . . . . . . . . . . . . . . . 8
4. Applicability to Legacy syslog . . . . . . . . . . . . . . . . 8
4.1. Method Change . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Octet-Counting . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Octet Stuffing . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Sender Authentication and Message Forgery . . . . . . . . 9
5.2. Message Observation . . . . . . . . . . . . . . . . . . . 10
5.3. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Message Prioritization and Differentiation . . . . . . . . 10
5.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
5.6. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11
6. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Gerhards & Lonvick Expires June 3, 2010 [Page 3]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
1. Introduction
The syslog protocol [RFC5424] is a text-based protocol used to convey
event information. Before that standard was produced, syslog
messages were being transmitted over UDP. This was described in the
INFORMATIONAL document [RFC3164]. While there has been no documented
standard for transporting syslog messages over TCP, it is widely used
in practice and has proven to be quite interoperable among the
implementations, with some minor issues in some configurations.
While existing implementations interoperate quite well with each
other, there are some differences in protocol handling. This
document will describe the most commonly used approach and explain
how to interoperate with them in a consistent way.
This specification applies to messages transmitted using the
[RFC5424] format. A discussion of how this may be applied to
[RFC3164] messages is contained below. This specification is written
this way, with two format options, in an attempt to ensure that
syslog transport receivers can receive and properly interpret
messages sent from legacy syslog senders.
It is still RECOMMENDED to use the TLS transport [RFC5424] to convey
syslog messages. This specification is provided to ensure
interoperability for transporting syslog over TCP.
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.
3. Message Transmission
As described in [RFC5424], syslog is simplex in nature. Traditional
TCP implementations 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. Reliability and flow control are provided by the
abilities of TCP.
Gerhards & Lonvick Expires June 3, 2010 [Page 4]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
3.1. Session
A syslog over TCP session is a TCP connection between a client and a
server. The syslog transport sender is the 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.
|
+<--------------------------+
| |
V |
+------------------+ |
| session initiate | |
+------------------+ |
| | success |
+------+ | |
|shutdown | +------------+ |
|failure V V | |
| +------------------+ | more |
| | send message | | messages |
| +------------------+ | |
| | | | |
| | +------------+ |
+--------+ | failure |
| | shutdown decision |
V V |
+------------------+ |
| session closure | |
+------------------+ |
| re-init |
+---------------------------+
Diagram 1. Transport Sender State Machine
Gerhards & Lonvick Expires June 3, 2010 [Page 5]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
|
+<--------------------------+
| |
V |
+------------------+ |
|listen for connect| |
+------------------+ |
| | success |
+------+ | |
|shutdown | +------------+ |
|failure V V | |
| +------------------+ | more |
| | receive message | | messages |
| +------------------+ | |
| | | | |
| | +------------+ |
+--------+ | failure |
| | shutdown decision |
V V |
+------------------+ |
| session closure | |
+------------------+ |
| re-init |
+---------------------------+
Diagram 1. Transport Receiver State Machine
A syslog transport sender is a simple state machine as shown in
diagram 1. A transport receiver is a simple state machine as shown
in diagram 2. It is valid (but rare) for no messages to be exchanged
during a TCP session.
Note the absence of any real error processing on the state machine.
If an error occurs, the peer detecting the error will gracefully
close the TCP session, but has no means to notify its remote peer
about the state of the peer syslog application.
3.2. Session Initiation
The peer that intends to act as a syslog transport receiver listens
to TCP port <TBD>. The peer 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 peers
Gerhards & Lonvick Expires June 3, 2010 [Page 6]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
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.
At least one message is encapsulated inside a frame. Transport
senders use one of two different framing formats. They MUST support
the octect-counting method and they MAY support the octet-stuffing
method. Syslog transport receivers are REQUIRED to support the
octet-counting method and are RECOMMENDED to support the octet-
stuffing method to promote interoperability with legacy devices that
may only use that framing method. Transport senders do not send any
notice about the format they use to the transport receiver. However,
the format itself enables the transport receiver to detect which
framing is used. The syslog transport sender MUST NOT change the
format after it has sent the first message. If the format needs to
be changed, the TCP session must be concluded and a new session
established.
The syslog message stream has the following ABNF [RFC5234]
definition:
APPLICATION-DATA = *SYSLOG-FRAME
SYSLOG-FRAME = SYSLOG-MSG TRAILER
SYSLOG-FRAME =/ MSG-LEN SP SYSLOG-MSG
MSG-LEN = NONZERO-DIGIT *DIGIT
SP = %d32
NONZERO-DIGIT = %d49-57
DIGIT = %d48 / NONZERO-DIGIT
TRAILER = LF | APP-DEFINED
LF = %d10
Figure 1
Note that APP-DEFINED is not specified inside the ABNF and is used as
a placeholder for slightly different terminators found in practice.
Gerhards & Lonvick Expires June 3, 2010 [Page 7]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
3.3.1. Octet-Stuffing
In octet-stuffing mode, there is no header, but a trailer is appended
after SYSLOG-MSG. For this specification, this character MUST be the
USASCII LF (%d10) character.
A transport receiver MUST accept that the TRAILER character is a
USASCII LF. It MAY be configurable to accept other characters. A
discussion of this may be found below.
It is recommended, and is current practice, that a transport receiver
assumes that octet-stuffing framing is used if a syslog frame starts
with the USASCII character "<" (%d60).
The octect-stuffing method is NOT RECOMMENDED.
3.3.2. Octet-Counting
This mode is somewhat similar to the framing used in [RFC5425]. Here
the message length, in octets, is specified as HEADER, followed by
SYSLOG-MSG and no trailer.
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.
It is recommended and current practice that a transport receiver
assumes that octet counted framing is used if a syslog frame starts
with a digit.
3.4. Message Content
SYSLOG-MSG is defined in [RFC5424]. Most senders use the format
described in [RFC3164] as an alternate format.
The syslog transport receiver MUST discard the TRAILER as it accepts
the packet. That is to say that if the TRAILER character is kept
with the message, then the message received will not be what was
sent, and it will also no longer be compliant with the format
specified in [RFC5424]
Gerhards & Lonvick Expires June 3, 2010 [Page 8]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
3.5. Session Closure
The SYSLOG session is closed when one of the peers decides to do so.
It then initiates a TCP session closure. It does not notify its
remote peer of its intension to close the session, nor does it accept
any messages that are still in transit.
4. Applicability to Legacy syslog
This is an informative section provided to promote interoperability
within the various observed implementations. Even though this
specification does not cover legacy syslog messages, the language
used here will be consistent with [RFC2119] to be clear in this and
to show how the new syslog architecture will interoperate with the
legacy implementations.
Syslog over TCP has been around for a number of years. Just like
traditional syslog, several different implementations exist. The
older method of octet-stuffing has problems so implementers are
encouraged to not use that mechanism. The newer method of octect-
counting is reliable and should be used.
It is recommended and current practice that a transport receiver
assumes that octet-counting framing is used if a syslog frame starts
with a digit.
4.1. Method Change
It has been observed in legacy implementations that the framing may
change on a frame-by-frame basis. That is to say that a transport
receiver SHOULD be prepared to accept different framing for each
frame received. Devices that wish to interoperate with these legacy
systems should be aware of this.
4.2. Octet-Counting
This framing allows for the transmission of all characters inside
SYSLOG-MSG. Some transport senders have been seen to use this
framing to stack multiple messages within a single TCP frame.
This method is REQUIRED for syslog transport receivers and senders.
4.3. Octet Stuffing
The problem with octet-stuffing framing comes from the use of
[RFC3164] messages. In that the traditional trailer character is not
escaped within SYSLOG-MSG which causes problems for the receiver.
Gerhards & Lonvick Expires June 3, 2010 [Page 9]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
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.
In this legacy implementation, the TRAILER consists of a single
character and most often is the USASCII LF (%d10) character.
However, other characters have also been seen occasionally, with
USACII NUL (%d00) being a prominent example. Some devices also emit
a two-character TRAILER, which is usually CR and LF. i
Transport senders MUST support the option to use the USASCII LF
character. Transport receivers MUST also support this. Transport
senders and receivers MAY also support other characters.
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 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 to a receiver 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.
Gerhards & Lonvick Expires June 3, 2010 [Page 10]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
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
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 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.
Gerhards & Lonvick Expires June 3, 2010 [Page 11]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
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.
6. Authors
The authors of this draft are:
Rainer Gerhards
Adiscon GmbH
Mozartstrasse 21
97950 Grossrinderfeld
Germany
Email: rgerhards@adiscon.com
Chris Lonvick
Cisco Systems, Inc.
12515 Research Blvd.
Austin 78759
USA
EMail: clonvick@cisco.com
7. 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.
8. Acknowledgments
This document was written using the xml2rfc tool described in RFC2629
[RFC2629].
Gerhards & Lonvick Expires June 3, 2010 [Page 12]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
The authors wish to thank and all other people who commented on
various versions of this proposal.
9. Notes to the RFC Editor
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.
10. References
10.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.
[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.
10.2. Informative
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
Gerhards & Lonvick Expires June 3, 2010 [Page 13]
Internet-Draft Transmission of Syslog Messages over TCP November 2009
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 June 3, 2010 [Page 14]
