I agree with Tom that the draft - at least IMHO - does not promote or strongly encourage reliable logging. I also agree with the observation that reliable - and blocking - logging can cause harm to a system. However, I do not think that this is anything that the protocol can do something against. It is not the protocol that causes harm. If we say "if we support a reliable syslog protocol, we can block the system and thus the protocol is harmful", we can also say "if we deliver mail messages via a reliable protocol (SMTP), we can use up all system ressources (e.g. fill the disk), so SMTP is harmful". My point is that we must differentiate between the protocol and its implementations. A reliable syslog protocol offers the foundation on which a reliable syslog implementation can be build. It is the task of the application designer to take care of the operating environment specifics while implementing the protocol. A good design for Unix will probably take into consideration that a blocking syslogd does not do any good and leave options to the operator to discard messages when needed (and probably have turned them on by default). Even in such a situation, however, a reliable syslog protocol has advantages. We can not accidently loose messages. The application must actively discard them. Which in turn means the application *knows* that messages have been discarded. It can convey that information to the other syslog applications it is talking to. In contrast, by using UDP messages get dropped and nobody knows. To prove my point, my open source syslog pet rsyslog has implemented active message discarding in case it would need to block (at least in single-thread mode, with multiple threads discarding occurs only after the queue space is used up). This was implemented because there is a real-world need for it. But this is application design, not protocol design. Think about it: how can an IETF document specify what a syslogd should do if its sending queue is filled up? How could we word this so that it becomes part of an on-the-wire protocol? Rainer
-----Original Message----- From: Tom.Petch [mailto:sisyphus@xxxxxxxxxxxxxx] Sent: Monday, February 05, 2007 8:06 AM To: Harald Tveit Alvestrand; ietf Subject: Re: draft-ietf-syslog-protocol: "Reliable deliveryconsidered harmful." <inline> Tom Petch ----- Original Message ----- From: "Harald Tveit Alvestrand" <harald@xxxxxxxxxxxxx> To: "David W. Hankins" <David_Hankins@xxxxxxx>; <ietf@xxxxxxxx> Sent: Sunday, February 04, 2007 9:43 PM Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." > Daring to rush in without having read the documents.... > > it seems to me that somewhere one needs a NOTE, something along the lines > of: > > NOTE: In some situations, for instance when a destination disk is full or > damaged, a syslog facility may be unable to process all messages, despite > the message transport being reliable. In such a case, it is reasonable for > the logger of a message to have the option of either not logging more > messages or ceasing its own operation. This document does not specify which > option to take. > > Or words to that effect. > > Harald > Harald It might be worth reading the I-D:-) I am not clear which piece of text in the I-D provoked the original comment. I do not see the I-D recommending reliable transport, with all the problems that have been identified with that. Rather, under security, the I-D points out that with an unreliable transport, losing critical messages may adversely impact operation. It then goes on to say " It may be desirable to use a transport with guaranteed delivery to mitigate congestion. It may also be desirable to include rate-limiting features in syslog senders. This can reduce potential congestion problems when message bursts happen." I find it hard to square this with the original statement that 'draft-ietf-syslog-protocol-19.txt recommends using a reliable protocol' If we were to put in a comment about reliable transports introducing problems with blocking, then I think that that should be in an I-D which specifies a reliable transport, eg the soon to be completed one on TLS (there are no plans for one with TCP). Tom Petch > > --On 2. februar 2007 09:59 -0800 "David W. Hankins" <David_Hankins@xxxxxxx> > wrote: > > > On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: > >> Wether it is a bug or a feature depends on your requirments. On some > >> high-security environments, people prefer to suspend the service > >> rather than not being able to log it. (Otherwise, an attacker could > >> easily attempt many attacks, fill in the hard disk and then perform > >> the real attack unlogged). > > > > I'd just like to point out that you're choosing one bug over > > another. A DOS in preference to lack of observance of events. > > > > In my opinion, that's a bad selection, but it's your selection to > > make. > > > > That kind of preference, that kind of choice, is a good thing to > > have, but it would be unwise to apply to the general case a > > systematic selection of DOS over observation. > > > > -- > > David W. Hankins "If you don't do it right the first time, > > Software Engineer you'll just have to do it again." > > Internet Systems Consortium, Inc. -- Jack T. Hankins > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf