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(_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
harmful."
<inline>
Tom Petch
----- Original Message -----
From: "Harald Tveit Alvestrand" <harald(_at_)alvestrand(_dot_)no>
To: "David W. Hankins" <David_Hankins(_at_)isc(_dot_)org>;
<ietf(_at_)ietf(_dot_)org>
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(_at_)isc(_dot_)org>
> 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(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Syslog mailing list
Syslog(_at_)lists(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf