[back]
Rainer Gerhards, Adiscon (written 2005-06-14)
This is my personal rant on what I think the future will bring for syslog. As you probably know, syslog is around for quite some while; it was created by Eric Allman in the early 1980s as part of the sendmail project. Since then, the basic protocol has not changed very much. There are some vendor-extensions, like the well-accepted syslog-over-plain-tcp (not to mistaken with RFC 3195).
Since ca. 2000, the IETF is standardizing syslog. IETF's goals are primarily increased security and reliability for the protcol. Of course, a "side-effect" is a formal standardization of the protocol itself. In early stages, IETF documented the protocol in RFC 3164, which is a purely information document (not a standard). Then, in RFC 3195, a reliable delivery method was defined. It bases on BEEP (RFC 3080/3081), which also offers the ability to encrypt the communication channel and authenticate sender and receiver. However, BEEP comes at the price of much increased complexity. There was (and is) much criticism from implementors that BEEP is "overly complex" for a protocol like syslog (some might call it "overkill" ;)). Though these arguments are at least partly true, one must admit that in order to build a solid protocol, some overhead is needed. If one tries to redo the procotol, one will quickly end with something similar to BEEP. I hope that the availability of my liblogging, a dedicated logging library, will help to grow acceptance of RFC 3195.
Stepping further in its work, the IETF is currently defining a new base standard, the core syslog format inside a layered architecture. You might want to have a look at my somewhat older, but still basically right presentation on syslog layered architecture if you are interested in this topic (just be sure to ignore the part about multi-part messaging!). This work, called syslog-protocol, will be at the bottom of upcoming syslog standards. Thus, it must be finished before any further work can be done. I hope this will finally happen within 2005. Once this is done, work on digital signatures in syslog can continue. Also, there is a draft on SNMP instrumenation of the syslog-subsystem.
Standardization is always a slow process. This is espcially true if the previous "version" works well and the new standards require considerate change. Both is the case in syslog. There seems to be few pressing needs to move forward [who cares about security ;-) ?] and little public interest at all. However, I am noticing slowly growing interest in the new standards, especially in RFC 3195. Definitely a driving force is the Integrating the Healthcare Enterprise (IHE) effort, which specifies syslog as part of the auditing process (and immediately has some issues with the current incompatibilities, which RFC 3195 at least partly solves). Also, as it looks, some major network equipment vendors seem to look at RFC 3195, and especially at its security features. If one of the major playes actually decides to enter the RFC 3195 space, I guess interest in it will increase exponentially.
Of course, good old plain UDP syslog is far from being dead. I expect it it keep a healthy life for at least another decade, if not much longer (what I expect). In my point of few, plain old syslog will probably stay in home devices (like SOHO DSL routers) for a very long time, whereas the new standards will move into the enterprise space within the next decade.
And, of course, I might be totally wrong ;)
This page last updated: Tue Oct 11 16:35:33 2011.
For content issues, contact rgerhards-at-adiscon.com - for legal issues, please contact Adiscon who is the legal owner and publisher of this web site.
Visit our topic pages for practical information on syslog.
Raw Mail Archive: [threaded] [by date] [search]