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?
From: Tom.Petch [mailto:sisyphus(_at_)dial(_dot_)pipex(_dot_)com]
Sent: Monday, February 05, 2007 8:06 AM
To: Harald Tveit Alvestrand; ietf
Subject: Re: draft-ietf-syslog-protocol: "Reliable deliveryconsidered
----- Original Message -----
From: "Harald Tveit Alvestrand" <harald(_at_)alvestrand(_dot_)no>
To: "David W. Hankins" <David_Hankins(_at_)isc(_dot_)org>;
Sent: Sunday, February 04, 2007 9:43 PM
Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered
> Daring to rush in without having read the documents....
> it seems to me that somewhere one needs a NOTE, something along the
> NOTE: In some situations, for instance when a destination disk is
> damaged, a syslog facility may be unable to process all messages,
> the message transport being reliable. In such a case, it is
> the logger of a message to have the option of either not logging
> messages or ceasing its own operation. This document does not
> option to take.
> Or words to that effect.
It might be worth reading the I-D:-)
I am not clear which piece of text in the I-D provoked the original
do not see the I-D recommending reliable transport, with all the
have been identified with that. Rather, under security, the I-D
points out that
with an unreliable transport, losing critical messages may adversely
It then goes on to say
" It may be desirable to use a transport with guaranteed delivery to
congestion. It may also be desirable to include rate-limiting
syslog senders. This can reduce potential congestion problems when
I find it hard to square this with the original statement that
'draft-ietf-syslog-protocol-19.txt recommends using a reliable
If we were to put in a comment about reliable transports introducing
with blocking, then I think that that should be in an I-D which
reliable transport, eg the soon to be completed one on TLS (there are
for one with TCP).
> --On 2. februar 2007 09:59 -0800 "David W. Hankins"
> > On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer
> >> Wether it is a bug or a feature depends on your requirments. On
> >> high-security environments, people prefer to suspend the service
> >> rather than not being able to log it. (Otherwise, an attacker
> >> easily attempt many attacks, fill in the hard disk and then
> >> 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 mailing list
Syslog mailing list
Ietf mailing list