Transmission of Syslog Messages over TCPAdiscon GmbHMozartstrasse 21GrossrinderfeldBW97950Germanyrgerhards@adiscon.comCisco Systems, Inc12515 Research Blvd.AustinTX78759USAclonvick@cisco.com
xxx
No home yetSYSLOGSYSLOG transport ssh
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.
The syslog protocol 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 .
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
format. A discussion of how this may be applied to 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 to
convey syslog messages. This specification is provided to ensure interoperability
for transporting syslog over TCP.
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.
The terminology defined in Section 3 of is
used throughout this specification. The reader should be familiar with
that to follow this discussion.
As described in , 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.
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.
Diagram 1. Transport Sender State MachineDiagram 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.
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 .
During the message transfer phase, the syslog transport sender sends a
stream of messages to the transport receiver. Either of the peers may initiate
session closure at any time as specified in Section 3.5
of . 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
definition:
Note that APP-DEFINED is not specified inside the ABNF and is used as
a placeholder for slightly different terminators found in practice.
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.
This mode is somewhat similar to the framing used in
. 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.
SYSLOG-MSG is defined in . Most senders use
the format described in 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
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.
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 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.
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.
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.
The problem with octet-stuffing framing comes from the use of
messages. In that the traditional trailer character
is not escaped within SYSLOG-MSG which causes problems for the receiver.
For example, a message in the style of
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.
Using this specification on an unsecured network is NOT RECOMMENDED.
Several syslog security considerations are discussed in
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
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.
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.
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.
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.
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.
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.
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.
The authors of this draft are:
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.
This document was written using the xml2rfc tool described in
RFC2629.
The authors wish to thank
and all other people who commented on various versions of this proposal.
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.