RE: [Syslog] timeline

Miao Fuyou <miaofy@huawei.com> Tue, 15 August 2006 07:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCsub-0003F4-Ou; Tue, 15 Aug 2006 03:00:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCsua-0003Ep-QS for syslog@ietf.org; Tue, 15 Aug 2006 03:00:28 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCsuY-0004Tm-Tv for syslog@ietf.org; Tue, 15 Aug 2006 03:00:28 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4100LCQ2KEQ4@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:09:51 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4100LWU2KE8F@szxga03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:09:50 +0800 (CST)
Received: from m19684 ([10.111.12.140]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4100IGJ297JM@szxml03-in.huawei.com> for syslog@ietf.org; Tue, 15 Aug 2006 15:03:10 +0800 (CST)
Date: Tue, 15 Aug 2006 14:59:28 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] timeline
In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174DF3@grfint2.intern.adiscon.com>
To: 'Rainer Gerhards' <rgerhards@hq.adiscon.com>
Message-id: <00ad01c6c038$59f29710$8c0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
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

Rainer,

Stunnel is a secure wrapper for TCP stream. Actually delimiting Syslog is
done in the TCP part rather than TLS (or stunnel) part in Syslog-ng with
stunnel. One can use stunnel to secure any Syslog TCP transport, such as
rsyslog and kiwisyslog, and kiwisyslog does use CRLF for delimiting
(http://www.kiwisyslog.com/whats_new_syslog.htm). 

Stunnel implementation is different from Syslog TLS transport, and I don' t
think it is the exact implementation of Syslog TLS transport. I have not
been aware of a Syslog implementation in TLS-transport style till now. So,
most of the implementation may be modified, slightly or heavily, to existing
code to get it comply to the specification. 

Miao

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Tuesday, August 15, 2006 12:41 PM
> To: Miao Fuyou
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] timeline
> 
> Miao,
> 
> I am actually concerned about backward compatibility with 
> existing code
> *without* the need to upgrade any of that code. As you know, 
> deployed software tends to stick.
> 
> If we use just LF, existing, deployed technology (e.g. syslog-ng with
> stunnel) would be able to understand a message sent from a "new style"
> syslogd. Having the octet count in front of the message 
> removes that ability, as the old syslogd will no longer see 
> the <pri> at the start of the message.
> 
> I agree that it is trivial to modify code to take care for 
> the octet counter. But this is not my concern. My concern is 
> that I would like to achive as good as possible compatibility 
> with existing deployed (aka
> "unmodified") technology. I should have been more specific on that.
> Sorry for the omission...
> 
> I am also unaware of any implementation that mandates CR LF 
> over just LF. Could you let me know which ones are these?
> 
> Rainer 
> 
> > -----Original Message-----
> > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > Sent: Monday, August 14, 2006 7:07 PM
> > To: Rainer Gerhards
> > Cc: syslog@ietf.org
> > Subject: RE: [Syslog] timeline
> > 
> >  
> > Hi, Rainer,
> > 
> > A new implementation could rely on byte-counting only and 
> then delete 
> > LF from the frame(appplication knows exactly where the LF 
> is), it may 
> > not force us to use escapes. For LF, I think it is difficult to get 
> > 100% compatibility for a legacy implementation to comply 
> TLS-transport 
> > without any change to the code. At least, some 
> imlementation may need 
> > to change CR LF to LF because some implementations use CR LF rather 
> > than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP 
> > from the frame.
> > 
> > I still prefer byte-counting only to byte-counting+LF even 
> if it is a 
> > feasible tradeoff.
> > 
> > Miao
> > 
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > > Sent: Monday, August 14, 2006 10:18 PM
> > > To: Miao Fuyou
> > > Subject: RE: [Syslog] timeline
> > > 
> > > We should not go byte-counting + LF. This is the worst choice: it
> > > 
> > > A) breaks compatibility
> > > B) Forces us to use escapes
> > > 
> > > So we get the bad of both worlds, without any benefits.
> > > 
> > > Rainer
> > > 
> > > > -----Original Message-----
> > > > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > > > Sent: Monday, August 14, 2006 12:58 AM
> > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';
> > > syslog@ietf.org
> > > > Subject: RE: [Syslog] timeline
> > > > 
> > > > 
> > > > My vote: byte-counting only > byte-counting + LF > LF
> > >  
> > > 
> > 
> > 
> > 
> 



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