Hi all - Sorry I missed the conference call today.
Apparently someone mentioned the related IETF working group. Its official
title is "Security Issues in Network Event Logging (syslog)" and its web
site is at
I haven't read *all* their documentation yet but it seems likely that
there's at least some overlap in what we're trying to do. I know that Rainer
Gerhards (who has recently joined this list) is actively involved -- Rainer,
can you give us a summary of what's going on?
cheers -- tbird
On Fri, 29 Aug 2008, Tina Bird wrote:
> Hi all - Sorry I missed the conference call today.
> Apparently someone mentioned the related IETF working group. Its official
> title is "Security Issues in Network Event Logging (syslog)" and its web
> site is at
> I haven't read *all* their documentation yet but it seems likely that
> there's at least some overlap in what we're trying to do. I know that Rainer
> Gerhards (who has recently joined this list) is actively involved -- Rainer,
> can you give us a summary of what's going on?
I recently joined and can give an update on this. I'm not sure how much
overlap there is. I'll lay out what the WG is working on and would be
glad to discuss on a future call.
Originally, the WG wanted to produce a reliable transport for syslog
without really touching the syslog message itself. We produced RFC 3195,
"Reliable Delivery for syslog" which has not been widely accepted even
though there are some opensource implementations available.
We also discussed how a syslog receiver would be able to verify what was
sent from a source without changing an essential characteristic of syslog
- a simple udp transport. (This is a basic characteristic for the IETF
which is mostly concerned with bits on the wire.) John Kelsey wrote the
original version of the syslog-sign Internet Draft which lays out how a
sender can sign groups of messages. A receiver can then ascertain the
proper order of transmission and any losses, duplicates or corruptions in
what it receives. We've had lengthy discussions about that and finally
concluded that we really couldn't do that work without properly defining
some parts of the syslog message; the date and time, the sending process
(subsystem or pid), etc. Rainer undertook that work and it's now about to
be published as an RFC.
We're still trying to separate the upper layer protocol from the transport
so we produced a separate document to show how the syslog protocol (as is
defined in Rainer's document) can be layered atop udp. It can also be
layered atop the transport defined in RFC 3195 but not too many people
seem to be interested in that.
Our AD at the time required us to produce a secure transport for syslog as
well. This was supposed to be an optional transport with udp being
required. However, during discussions the IESG determined that a
udp-based protocol was not going to cut it as it does not provide
congestion control. From that, the WG accepted that the tls transport can
be required to satisfy the IESG requirements. Several people on the WG
list have expressed that they feel that udp will still be the prevalent
transport for syslog regardless.
At this time, the IESG has accepted
We're working on some final wording for
These are all dependent upon each other so the RFC Editor will not publish
any until all have been approved by the IESG.
Once that's complete we will again focus on draft-ietf-syslog-sign and
hopefully complete that very quickly.
Along the way, we did produce a set of Textual Conventions for syslog in
draft-ietf-syslog-tc-mib but we have not produced a full set of mibs.
An interesting thing from syslog-protocol which might overlap the CEE
effort is the use of "structured data". From the ID:
STRUCTURED-DATA provides a mechanism to express information in a well
defined, easily parseable and interpretable data format. There are
multiple usage scenarios. For example, it may express meta-
information about the syslog message or application-specific
information such as traffic counters or IP addresses.
Hope this helps.
|Free forum by Nabble||Edit this page|