Author: Rainer Gerhards

Hi folks,

long time no post, but now one is really due…

Let’s wrap up: The IETF is trying to standardize and evolve the syslog protocol. Syslog is in wide-spread use for system and network monitoring, both in small and large-scale environments. Though widely used, it has never been standardized and is inherently insecure. The IETF syslog working group is trying to change this. During the work, a proposal for a (TLS) secured syslog protocol has been developed, a real group effort. This proposal reflects what already is done in practice (just google for “syslog ssl” and you see what I mean…).

Now, Huawei (the authors of the standard document belong to them) claims an undisclosed patent on this work. This in turn has lead to a standstil of the standardization effort plus a search for alternate, less efficient and more complex solutions to the problem.

The full story can be obtained from the working group’s mailing list archive. It started with this message:
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00593.html

The discussion can be followed by reading the top half posts on this page:
http://www.mail-archive.com/syslog%40lists.ietf.org/maillist.html

Two of my favourite rants in the discussion are these:
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00657.html
http://www.mail-archive.com/syslog%40lists.ietf.org/msg00620.html

Isn’t that cool? It is a nice example of how useful that current software patent system really is.

Happy legalizing,
Rainer

Yesterday I have finished the 16th version of the syslog-protocol internet draft and sent it to the IETF for publishing. It now addresses (almost?) all issues that were brought up in Vancouver and thereafter. In the mean time, the IETF has still made no final decision on the future of the syslog-sec WG. As Chris says, it is likely to stay and the new charter to be accepted. I just wonder if we finish that work until spring…

Long time no post ;) It has been busy days, with finaly a healthy discussion on the IETF syslog-sec mailing list. Still, there are (too) few participants, but it looks like the recent events got the group some momentum. The WG is now in danger of being shut down and that seems to drive activity. A new charter is being discussed. It looks like the rejection of previous work will lead to a really good alternative. It is still too early to be sure all will have a good outcome, but in my opinion it looks more promising than any time the past month – especially if you think about a spec becoming implemented.

Sam Hartman (IETF Security Area Director) has rejected the syslog-protocol draft due to missing support in the last IETF meeting. I do not yet know which new non-concensus turned up. I fear it is an re-iteration of arguments already exchanged. I am very curios to have a look at the minutes. Anyhow, if it is yet another re-iteration, I seriously begin to doubt if that activity makes any sense at all… Maybe it is a much better idea just to create some simple TCP-based syslog format, talk to the other implementors… and do it ;)

I’ve talked with a lot of people about rfc3195 to lots the past days. I’ve a mixed feeling. Since spring, rfc 3195 is getting momentum. On the other side, the IETF syslog-sec WG is considering removing some parts from RFC 3195 (namely the COOKED profile). The adoption rate in practice is also very low…

Anyhow, the discussions indicated that a lot of folks seem to work on rfc 3195 (well, “a lot” in my terms…), but most of them somewhat isolated. I will now try to solve this issue with a new mailing list. Maybe we can even get some IHE folks onboard.

The list charter is as follows:

###
The rfc3195 list is targeted towards people interested in RFC 3195-based solutions. It is primarily aimed at implementors, protocol-designers and operators who would like to have insight into the protocol and the various implementations. It carries deeply technical content about protocol interpretations, interoperability of different RFC 3195-based solutions, and discussion about the future of RFC 3195. It also covers news and annoucements about RFC 3195-related projects and products. These items should not be marketingish but rather help inform the community of new arrivals and other important events.
####

Subscription information is available at

http://lists.adiscon.net/mailman/listinfo/rfc3195

I hope this is a useful tool for the community. Let’s see how it evolves.

Today, I have released rsyslog 1.11.1. It now supports BSD config file extension for hostname and program blocks. Initialy, it caught me by surprise that BSD has such considerable extensions. Actually, it looks like I picked the wrong starting point with sysklogd. BSD’s syslogd is much more capable (e.g. it has IPv6!) and the code looks somewhat cleaner. Anyhow, now we are too far in the game to reconsider anything. Plus, there is not much code left from the orginal sysklogd. In lines of code, I think rsyslogd has roughly 2.5 times as much code then sysklogd (hopefully not only consisting of bugs ;)).

Today, I’ve also brought over some patches from sysklogd to those remaining code pieces in rsyslogd. The sysklogd team is *very* conservative with updating the package. In its CVS, there are a number of non-intrusive yet slightly important patches which have not yet made it into the source. The “current” version is now rougly 2 years old… Anyhow, I think I have finally build a considerably more capable and also reliable syslogd than what I started with. It’s still a way to go, but I begin to like what I have done. :)

I am a bit late in posting this. After “last call”, syslog-protocol went to AD review. On September 19th, 2005, Sam Hartman has replied with a number of very good questions and suggestions. Obviously, that has pushed us a bit back, but it also has fingerpointed to some very important issues. While I am not happy that syslog-protocol will probably take much longer to complete, I am happy to get it as good as possible. Sam has also mentioned that he will have it reviewed by a number of operators, which is a big plus given the sparse feedback we had so far from that community.

In the mean time, I have looked at most issues on Sam’s list and done some text changes. I am right now finalizing on Unicode security, the last thing with outstanding suggestions and feedback by the WG. Hopefully, I’ll be able to find consensus some time next week.

Chris has called for a meeting at the next IETF (in November), and I hope to meet the October 24th draft submission deadline. Then, the meeting can hopefully reach decision. It’s a shame I can’t attend, but it is hardly justifiable for Adiscon to travel to Vancouver for an one hour slot…

An interesting fact is that Chris also has put re-consideration of RFC 3195 on the agenda. It is only very slowly getting implemented. My personal view is that it is too early to dump it, implementations are now beginning to be seen. I am most interested how this continues…

Long time, no post. But now I am really excited. Finally, I have managed to get RFC 3195 functionality into rsyslog. The 1.11.0 release contains just the listener (aka “server ;)), and the code definitely can be improved. But, after all, this is a big step for rsyslog. Esepcially, if you consider that the original project goals called for immediate implementation of RFC 3195. Even the name – rsyslog – stems back to RFC 3195 (reliable syslog!). Well, it turned out that other needs were in much more in demand, and so RFC 3195 was postponed and postponed…

Still, we do not have the initiator (sender) and not the greatest code. But at least we can now see if there is growing demand. I expect so, but only slowly. I will see that I can integrate the initiator shortly, but I will first have a look into multithread-enabling rsyslogd. That would facilitate some of the RFC 3195 (synchronous) requirements and it probably is also needed to implement openssl with sufficiently performance (and thus low to no message loss).

But for now, I am happy with where I am arrived ;)

Finally, I have been able to do some major feature editons. Now the development branch somewhat gets off. See the change log for rsyslog 1.10.0 to see what I mean ;)

I have to admit that creating this release was more effort than I initially estimated. While I was right that the base design allowed neat integration of the new filtering, a lot of infrastructure (counted strings, parser, …) had to be added. Of course, these additions will help in the future, too. But as I said… it took much longer than expected. I ended up adding 1,000 lines of code and also modifying others. So roughly about 1/6th to 1/7th of the project needed to be changed to make this feature a reality…

It is finally done: rsyslog 1.0.0 is released. This is the first (officially ;)) stable branch. I’ve taken some weeks of close-to-no modifications to make sure as many bugs as posisble have been found and removed. I am very positive this release is really stable. I also hope that the availability of a stable release will help grow acceptance of rsyslog. All in all, we are now scoring within the top 5,000 projects on freshmeat.net (by popularity), which I think is not bad for such a new project in the logging area. I also already got some helping hands (more soon), so this is also an excellent sign.

Now that 1.0.0 is out, I will begin new feature enhancements – which will bring even more usefulness tp rsyslog.