RE: [Syslog] byte-counting vs special character

"David Harrington" <ietfdbh@comcast.net> Thu, 17 August 2006 15:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkEd-0002eJ-5K; Thu, 17 Aug 2006 11:56:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkEb-0002dx-Ob for syslog@ietf.org; Thu, 17 Aug 2006 11:56:41 -0400
Received: from alnrmhc14.comcast.net ([204.127.225.94] helo=alnrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDkEa-0006W4-En for syslog@ietf.org; Thu, 17 Aug 2006 11:56:41 -0400
Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (alnrmhc14) with SMTP id <20060817155635b1400glpt2e>; Thu, 17 Aug 2006 15:56:35 +0000
From: David Harrington <ietfdbh@comcast.net>
To: "'tom.petch'" <cfinss@dial.pipex.com>
Subject: RE: [Syslog] byte-counting vs special character
Date: Thu, 17 Aug 2006 11:54:56 -0400
Message-ID: <0c3301c6c215$7d47b130$0400a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <006e01c6c1e5$39c4ace0$0601a8c0@pc6>
Thread-Index: AcbB7lWmMlyQEV5RSSihbwXq/h9xeQAG8ozg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
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

Hi Tom,

[speaking as a contributor]

Rainer asserted that using LF would not break existing
implementations. It does not appear to me that we have reached
consensus that this assertion is true. I personally have concerns
because this WG has already found that many syslog implementations are
not compatible, especially on the point of having reserved/escaped
control characters for special use. I asked if Rainer could provide
any empirical support for his assertion, or whether his assertion was
theoretical. 

I have not asserted that a message containing an octet count would
work with existing implementations; only syslog implementations that
were updated to support the not-yet-defined <syslog/tls> standard
would use octet counting. 

Legacy messages without an octet-count would continue to be sent to
the legacy syslog port, presumably one by one or delineated using
whatever mechanism the legacy implementation currently supports. 

As I see it, a syslog/tls implementation would prepend an octet-count
field to each syslog message, concatenate the messages into a stream,
and send the concatenated messages to the new <syslog/tls> port. An
implementation that supports the syslog/tls standard would strip off
the prepending octet-count and extract each counted syslog message
from the stream. Each extracted message could then be processed using
the exact same parser code as would be used for messages received at
the legacy syslog port. 

Using an octet-count encapsulation technique like this means the
existing syslog message is not touched in any way, and the presence of
an octet-counted stream delivered to a special port expecting the
octet-counted stream, cannot interfere with any existing assumptions
about the message format or content. 

Note that the syslog messages encapsulated by the octet-count might be
able to be of any syslog format. The legacy parser implementation
(whichever of the many incompatible variations) would not be changed.
If the ability to carry different formats of syslog messages is
desired, an additional field should probably be prepended to each
syslog message in the stream that identified which syslog parser
should be used to parse it. I am not a supporter of this approach
because I would rather see implementations move to the syslog-protocol
standard, but for those who value backwards compatibility above all
else, this might be an interesting property.

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com] 
> Sent: Wednesday, August 16, 2006 1:08 PM
> To: David Harrington
> Cc: syslog@ietf.org
> Subject: Re: [Syslog] byte-counting vs special character
> 
> ----- Original Message -----
> From: "David Harrington" <ietfdbh@comcast.net>
> To: "'Rainer Gerhards'" <rgerhards@hq.adiscon.com>
> Cc: <syslog@ietf.org>
> Sent: Tuesday, August 15, 2006 7:24 PM
> Subject: [Syslog] byte-counting vs special character
> 
> 
> > Hi Rainer,
> ><snip>>
> > [speaking as contributor]
> > I like the argument that the LF solution will not break existing
> > implementations, but I would like to know this is actually 
> true. Have
> > you actually tested this against multiple implementations, 
> or is it a
> > theoretical argument?
> >
> Turning the argument around, how many implementations have 
> you got and have
> tested for interoperability that use byte counting for syslog?
> 
> As Rainer's posts and earlier work as documented on his web 
> site show, there is
> an awful lot of syslog out there, more pre-existing, interoperable
> implementation than in any other activity of the IETF I have 
> been involved with.
> For me, this overcomes any technical, architectural considerations
of
> 'betterness' and says we must go with our best understanding 
> of the existing
> marketplace (I thought differently when I started:-(
> 
> Other participants on this list may only represent a little 
> of the implemented
> code but it is still an awful lot of pre-existing implementation.
> 
> Tom Petch
> 
> 
> 
> > I know you have tested a number of other proposed ways of 
> doing things
> > against multiple implementations to try to verify backwards
> > compatibility. Have you actually tested multiple existing
> > implementations with the LF and found that they do continue to
work
> > without significant problems? Can you tell the WG which 
> ones you have
> > tested? Are there implementations that break when using 
> this solution?
> >
> >
> > dbh
> >
> >/syslog
> 


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