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:[EMAIL PROTECTED] > Sent: Tuesday, August 15, 2006 10:26 PM > To: Miao Fuyou > Cc: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > Sent: Tuesday, August 15, 2006 12:59 AM > > To: Rainer Gerhards > > Cc: [EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > > Sent: Tuesday, August 15, 2006 12:41 PM > > > To: Miao Fuyou > > > Cc: [EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > > > > Sent: Monday, August 14, 2006 7:07 PM > > > > To: Rainer Gerhards > > > > Cc: [EMAIL PROTECTED] > > > > 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:[EMAIL PROTECTED] > > > > > 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:[EMAIL PROTECTED] > > > > > > Sent: Monday, August 14, 2006 12:58 AM > > > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington'; > > > > > [EMAIL PROTECTED] > > > > > > 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
