RE: [Syslog] byte-counting vs special character

Balazs Scheidler <bazsi@balabit.hu> Wed, 16 August 2006 10:25 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDIa5-0006hV-Jk; Wed, 16 Aug 2006 06:25:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDIa4-0006hO-SZ for syslog@ietf.org; Wed, 16 Aug 2006 06:25:01 -0400
Received: from balabit.hu ([82.141.167.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDIa2-0005T6-9e for syslog@ietf.org; Wed, 16 Aug 2006 06:25:00 -0400
Subject: RE: [Syslog] byte-counting vs special character
From: Balazs Scheidler <bazsi@balabit.hu>
To: Carson Gaspar <carson@taltos.org>
In-Reply-To: <C136C3E9AA2A5B0FE58F3084@[192.168.1.2]>
References: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco .com> <C136C3E9AA2A5B0FE58F3084@[192.168.1.2]>
Content-Type: text/plain
Date: Wed, 16 Aug 2006 12:24:51 +0200
Message-Id: <1155723892.6352.67.camel@bzorp.balabit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

On Tue, 2006-08-15 at 13:50 -0700, Carson Gaspar wrote:
> I've been mostly lurking lately, but I would like to re-iterate my support 
> for byte counting. It's the Right Thing To Do, and theoretical "backwards 
> compatibility" with existing non-standard non-widely-deployed syslog over 
> TCP solutions isn't a good enough reason to put bad ideas in the standard.

Then why on earth did the BEEP based syslog/RAW use LF as line
terminator?

Quoting RFC3195:

   If multiple syslog messages are included in a single ANS reply, each
   is separated from the preceding with a CRLF.  There is no ending
   delimiter, but each syslog event message body length MUST be 1024
   bytes or less, excluding BEEP framing overhead.  Note that there MUST
   NOT be a CRLF between the text of the final syslog event message and
   the "END" marking the trailer of the BEEP frame.

As it currently stands:
  * nonstandard, but widely deployed syslog over TCP use LF
  * nonstandard, less widely deployed syslog-over-TCP-over-SSL use LF
  * standard, even less widely deployed syslog/RAW uses CRLF
  * semi-standard, UDP based syslog uses UDP packet framing for message
termination

Syslog-ng has supported TCP transport since its first release in 1998, a
number of devices interoperate with it. Whatever the decision of the
working group, syslog-ng will need to support this legacy TCP mode of
operation for backward compatibility. And as there is little incentive
for a user to change to the byte-counted form, I think the legacy mode
will still be more widely used for a couple of years to come.

Of course syslog-ng might not be the most widely deployed syslog
implementation, but I'm sure it is in the top three. Some numbers using
google search, which I know is not really representative:

sysklogd    607000 (default on Linux, no TCP support)
syslog-ng   593000
kiwi syslog 321000
msyslog     33400
sdsc syslog 21900
rsyslog     21500

In my opinion we either design something that is really sexy
(application layer acknowledgements, authentication, compression,
something that BEEP based syslog provides but which has other problems)
or we should be as compatible with existing installations as possible.

In my opinion the goal here is that the user will not need to change its
configuration file, or will not need a separate port on her firewalls, a
simple software upgrade on either receiver/sender and be done with it.

The current TCP based protocol _is_ implemented in closed-box devices
where replacing the sender software component is not possible or
feasible, if the new feature is incompatible, it will be difficult to
convince users to change, unless some real value is also added, other
than "byte-counted" form is cleaner. I tend to agree that byte-counting
is cleaner, I just don't see the advantate in the current state of
affairs.

-- 
Bazsi


_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog