RE: [Syslog] timeline

"Rainer Gerhards" <rgerhards@hq.adiscon.com> Wed, 16 August 2006 15:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNgy-0008GB-0p; Wed, 16 Aug 2006 11:52:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDNdl-0007Di-FJ for syslog@ietf.org; Wed, 16 Aug 2006 11:49:09 -0400
Received: from mail.hq.adiscon.com ([84.245.151.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDNUX-0007fc-Ci for syslog@ietf.org; Wed, 16 Aug 2006 11:39:39 -0400
Received: from localhost (localhost [127.0.0.1]) by mail.hq.adiscon.com (Postfix) with ESMTP id 76A2F9C00C; Wed, 16 Aug 2006 17:40:56 +0200 (CEST)
Received: from mail.hq.adiscon.com ([127.0.0.1]) by localhost (mail.grf.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18807-09; Wed, 16 Aug 2006 17:40:51 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (grfint2 [172.19.0.6]) by mail.hq.adiscon.com (Postfix) with ESMTP id CD4EF9C00B; Wed, 16 Aug 2006 17:40:51 +0200 (CEST)
Subject: RE: [Syslog] timeline
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Aug 2006 17:39:21 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA174DFF@grfint2.intern.adiscon.com>
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
In-Reply-To: <007401c6c11a$ee589110$8c0c6f0a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Syslog] timeline
Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAAtEhEAARtJ0AACebwIAADTn+wA==
From: Rainer Gerhards <rgerhards@hq.adiscon.com>
To: Miao Fuyou <miaofy@huawei.com>
X-Virus-Scanned: by amavisd-new-2.3.3 (20050822) (Debian) at adiscon.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
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

Miao,

I need to leave, thus short: To the best of my knowledge, a native
sender can talk to an stunnel-enhanced receiver. I am pretty sure I have
tested this, but I can not verify due to missing lab abilities right
now. Maybe somebody else could try it out. AFAIK the stunnel manual also
describes that scenario.

This ability is my #1 reason why I think escaping is superiour to
octet-couting.

Rainer

> -----Original Message-----
> From: Miao Fuyou [mailto:miaofy@huawei.com] 
> Sent: Wednesday, August 16, 2006 4:01 AM
> To: Rainer Gerhards
> Cc: syslog@ietf.org
> Subject: RE: [Syslog] timeline
> 
> 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