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:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 4:01 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > 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:[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
