Good points Anton, My preference is also for using SSL/TLS. From an implementers point of view, there is a good supply of SSL/TLS components and source code available (both commercial and open source). This would make it easy for customers to add secured syslog support to their apps.
We currently use SSH in our secure syslog tunnel app, but could replace it with SSL very easily. I heard that Rainer is going to add SSL support soon as well. Please, no one suggest we try and run the secure protocol over UDP :-) Let's keep to TCP as the transport for the secure/reliable protocol and keep using UDP for the simple send and forget system. The idea is to make it as simple as possible for a programmer to make his application/appliance send syslog messages. Grab an SSL library, choose a socket stack and Bob's your mother's brother. I believe that one of the reasons that 3195 is so slow to take off is that it is not easy to create an implementation from scratch. It is a lot easier to just grab a UDP socket library and put <PRI> at the start of each message. Simple is as simple does. Cheers Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, 26 October 2005 4:11 a.m. To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] Secure substrate - need your input > Hi Folks, > > I'll be asking this in Vancouver but would like to get some > input from the mailing list. > > Our charter says that we will develop a secure method to > transport syslog messages. We have BEEP (RFC 3195) but it > has a low implementation record. > Other groups have specified BEEP as well but are also moving > along towards using SSH or SSL. > > > 1) What secure substrate should the WG look towards: > > __ ssl > > __ ssh > > __ dtls > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > __ other I believe it should be SSL 3.0 / TLS 1.0. At least in web-server farm environments, you got SSL everywhere with a bunch of SSL accelerator hardware already in place. I also think several mappings can be defined. I am not a fan of options when it comes to standards, but allowing syslog over any kind of secure transport is a good thing. This was the whole idea of separating syslog-protocol from syslog-transport. Frankly, I don't think it will be a lot of work to define those transport mappings. > 2) Why? SSL/TLS is the most widely deployed network security protocol today. All e-commerce happens over it. Dozens of companies provide all shapes and forms of SSL accelerators. Many routers now have SSL accelartor modules. If I need to manage a large environment of servers where distributed logging really makes sense, being able to re-use existing infrastructure for scaling really helps. A search for "SSH accelerator" on google does not reveal anything interesting, but "SSL accelarator" shows up with a bunch of listings, several of which claim thousands of new SSL sessions per second. This confirms my experience. BTW, with SSL session caching, accelerators (ie. load balancers) can do 100,000 connections per second and more. So, to scale syslog over SSH would I have to wait for SSH accelerators to come to market? I see that there is a lot of work around SSH connection protocol and its potential use in new protocols. I have not followed these developments. There must have been a good reason for it. I would like to understand why people object to SSL, which is a well established technology. Any pointers? Thanks, Anton. > > > > Thanks, > Chris > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
