Subject: Re: draft-ietf-syslog-protocol: "Reliabledeliveryconsidered harmful."

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 8 Feb 2007 14:32:00 +0100

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:[email-masked]]
> 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" <[email-masked]>
> To: "David W. Hankins" <[email-masked]>; <[email-masked]>
> 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"
> <[email-masked]>
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Feb 2007 13:16:12 -0800

> (SMTP), we can use up all system ressources (e.g. fill the disk), so

RFC2821 (SMTP) defines a queueing behaviour and that servers should
retry transmission for "some reasonable number of times at intervals
as specified in section 4.5.4." should there be problems at the
reliable transmission layer.

It seems your example does what the syslog draft does not, so I'm
not sure what your point really is.

> needed (and probably have turned them on by default). Even in such a

You must differentiate between the protocol and implementation, but
not to the extent of denying the implementor guidance on how to
proceed in a way that will promote the health of the protocol.

The wholesale promotion of reliable transport without the disclaimer
that the protocol-level process probably wants to enter into discarding
behaviour in effect promotes the unhealthy condition.

My hope is that a simple acknowledgement of this evidently common
"implementation mistake" would substantially increase the quality of
syslog implementations that are updated for it.

> this so that it becomes part of an on-the-wire protocol?

If you were going to update syslog so that it might be transported
over a reliable channel, then I think the only right answer is to
define how the protocol-level process, independent of which reliable
transport is selected, deals with congestion or failure.

Barring that, there are many duct tape approaches.

Updating the security section to weigh the cons of denial of service
against the pros of reliable delivery.

Adding a glossary entry for "reasonably reliable", and using such
terms instead of the absolute "reliable" as is currently in place.

Numerous others.