RE: [Syslog] timeline

Miao Fuyou <miaofy@huawei.com> Wed, 16 August 2006 18:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQKu-0000j6-9P; Wed, 16 Aug 2006 14:41:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDQKt-0000iz-KL for syslog@ietf.org; Wed, 16 Aug 2006 14:41:51 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDIQT-0004rp-GB for syslog@ietf.org; Wed, 16 Aug 2006 06:15:05 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDIHb-0000Hd-Ng for syslog@ietf.org; Wed, 16 Aug 2006 06:06:06 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4300H4W5ZTKM@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:19:05 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J43005QS5ZSCM@szxga02-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:19:04 +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 <0J4300A935CHWH@szxml03-in.huawei.com> for syslog@ietf.org; Wed, 16 Aug 2006 18:05:08 +0800 (CST)
Date: Wed, 16 Aug 2006 18:01:23 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] timeline
In-reply-to: <577465F99B41C842AAFBE9ED71E70ABA174DF8@grfint2.intern.adiscon.com>
To: 'Rainer Gerhards' <rgerhards@hq.adiscon.com>
Message-id: <007401c6c11a$ee589110$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+AAD6HKgAAVuHhAAAhRtsAAAtEhEAARtJ0AACebwIA=
X-Spam-Score: -2.3 (--)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
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,

As you know, in stunnel/syslog model, a syslog sender sends syslog message
in TCP transport to a local port of the stunnel client, it then forwards it
to the stunnel server on another host in a TLS secure tunnel. After stunnel
server received the message it sends the message to the receiver on the same
host.  Basically stunnel is a port forwarding facility for application(any
application in TCP transport, not only syslog), and stunnel client and
server are both stand-alone applications co-locating on same host with
syslog sender or receiver application. 

Transport-tls requires a secure transport mechanism for Syslog, that means
the TLS transport is part of the sender/receiver application rather than
another stand-alone application. So, I believe stunnel/syslog is not the
exact implementation for transport-tls. 

I have not checked whether a transport-TLS sender can works well with a
"stunnelized" receiver or vice versa because there are not available
transport-tls implementation currently. It may be possible, however, is such
interaction capability a requirement for transport-tls?

Thanks!
Miao

> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Tuesday, August 15, 2006 10:26 PM
> To: Miao Fuyou
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] timeline
> 
> Miao,
> 
> Rsyslog accepts CRLF, and can even be configured to emit it.
> 
> I have no access to a lab. Could you please clarify where 
> exactly -transport-tls is unable to work with currently 
> existing deployments using stunnel? I would greatly 
> appreciate insight as I can not try it out for a while (and I 
> am also unable to do any in-depth analysis).
> 
> Thanks,
> Rainer 
> 
> > -----Original Message-----
> > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > Sent: Tuesday, August 15, 2006 12:59 AM
> > To: Rainer Gerhards
> > Cc: syslog@ietf.org
> > Subject: RE: [Syslog] timeline
> > 
> > 
> > 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