Subject: [Syslog] FW: Initial Logging capabiltiies document

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Jul 2006 12:08:39 -0400

FYI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
patrick cain
Sent: Wednesday, July 05, 2006 10:33 AM
To: [email-masked]
Subject: Initial Logging capabiltiies document

Hi,

I promised to get out a version of the logging capabiltiies document.
Since
I missed the initial draft cutoff date, I spent some extra time
flushing it
out. And it is attached. It will go to the IETF repository as soon as
it
re-opens.  Please advise me of correction, complaints, and aditions,
and
feel free to spam it others you may know who are into logging.

I asked for agenda time at the Montreal OPSEC meeting, but I don't
think
this one needs much presenting.

Pat Cain
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 7 Jul 2006 11:25:43 +0200

Quick review:

Section 2.3:

It looks like the syslog-ng option is vendor specific. In practice,
there are many implementations that interoperate with "plain tcp
syslog". At least these I know: Cisco PIX, Kiwi Syslog Daemon, rsyslog,
Adiscon MonitorWare, EventReporter & WinSyslog and probably SDSC syslogd
(not totally sure about that). Some of them are running on Windows, so
the protocol also works cross-platform.

Considerations:
It should be stated that it sometimes is more desirable to have
unreliable delivery. Reliable delivery means that the sender must slow
down when the receiver can not process fast enough. There have been
reports that such a slow-down might be unacceptable if that means a
high-performance application needs to wait for the logging. What is more
desirable obviously depends on the actual situation and the operator's
choice (and/or legal requirements).

Reliable delivery could cause a "domino DoS effect", if the senders
block while reconnecting. Popular samples are blocking PIXes whom's
syslogd has died. The same can be constructed for *nix systems reporting
via reliable syslog to a died central one. In that case, applications
(e.g. SMTP MTA) log synchronously to the syslogd, which tries to
forward. The local syslogd block. The synchronous logging API blocks
shortly after. This results to a standstill of the system as whole.

I see this is somewhat covered in 2.16, maybe a pointer would be
helpful.

Section 2.4
Supported Practices
add Tunneling via SSL

Current Implementations
Using stunnel together with syslog/plain tcp capable applications (e.g.
syslog-ng) is common practice.
Some samples:
http://www.google.com/search?sourceid=navclient-ff&ie=UTF-8&rls=GGGL,GGG
L:2006-13,GGGL:en&q=syslog+ssl
http://www.stunnel.org/examples/syslog-ng.html 
http://freshmeat.net/articles/view/1781/

General common on timestamp-related sections: 
current syslog practice is inadequate. syslog-protocol is trying to fix
that. Even after syslog-protocol has become a RFC, inadequate timestamps
will stay for a long time IMO. A mitigation is that the receiver records
the time of reception.  Given a sufficiently fast network, that
reception timestamp could be sufficient by itself. It would also be
possible to compute a delta between the message and the reception
timestamp and try to find a correction factor. I do not know of any
effort to try such a thing.

Section 2.17.2

I think the first sentence should not read "TCP port numer" but "port
number". Syslog usually travels via UDP and only occasionally via TCP
(RFC 3195 & non-standard but widespread used plain tcp syslog).

Section 3
general comment: current syslog servers "compress" repeat messages
("message repeated n times"). The compression happens at the sender.
This is sometimes desirable, but can lead to information loss. I suggest
this method is described.

Rainer

> From: David Harrington [mailto:[email-masked]] 
> Sent: Wednesday, July 05, 2006 6:09 PM
> To: [email-masked]
> Subject: [Syslog] FW: Initial Logging capabiltiies document
> 
>  FYI.
>