Subject: [Syslog] Revised proposed charter

From: Chris Lonvick <[email-masked]>
Date: Wed, 23 Nov 2005 09:05:25 -0800 (PST)

Hi All,

==== v2 of proposed charter ===

Syslog is a de-facto standard for logging system events.  However, the 
protocol component of this event logging system has not been formally 
documented.  While the protocol has been very useful and scalable, it has 
some known security problems which were documented in RFC 3164.

The goal of this working group is to address the security and integrity 
problems, and to standardize the syslog protocol, transport, and a select 
set of mechanisms in a manner that considers the ease of migration between 
and the co-existence of existing versions and the standard.

syslog has traditionally been transported over UDP and this WG has already 
defined RFC 3195 for the reliable transport for the syslog messages.  The 
WG will separate the UDP transport from the protocol so that others may 
define additional transports in the future.

- A document will be produced that describes a standardized syslog
protocol.  A mechanism will also be defined in this document
that will provide a means to convey structured data.

- A document will be produced that describes a standardized UDP
transport for syslog.

- A document will be produced that describes a standardized mechanism
to sign syslog messages to provide integrity checking and source
authentication.

=== ===

Comments please.

Thanks,
Chris

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

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Thu, 24 Nov 2005 19:33:17 +0900

Chris,
     You seem to have dropped the last deliverable which is in good shape

>     - A MIB definition for syslog will be produced.

I would strongly recommend that we include it. It is an important aspect
of the protocol. Some effort has gone into it. And it is the least
controversial [there are no issues of backward compatibility]. And it
is very close to completion.

Glenn

Chris Lonvick wrote:
> documented.  While the protocol has been very useful and scalable, it
> has some known security problems which were documented in RFC 3164.
> 
> problems, and to standardize the syslog protocol, transport, and a
> select set of mechanisms in a manner that considers the ease of
> migration between and the co-existence of existing versions and the
> standard.
> 
> syslog has traditionally been transported over UDP and this WG has
> already defined RFC 3195 for the reliable transport for the syslog
> messages.  The WG will separate the UDP transport from the protocol so
> that others may define additional transports in the future.
> 
>

---

From: Darren Reed <[email-masked]>
Date: Sat, 26 Nov 2005 10:07:05 +1100 (EST)

Chris,

Let me have a go at rewriting the charter...

The goal of this working group is to address the security and integrity
concerns about individual messages, as well as to standardise the message
format and the mechanisms used to transport those messages.  A primary
requirement of this work is to make it accept the traditional BSD format
syslog message.

> define additional transports in the future.

In RFC 3164, this WG documented the historical syslog protocol over UDP.
The WG then proceeded to develop a reliable transport for syslog messages
and this can be found in RFC 3195.  Using this work, we intend to develop
a number of documents that evolve the syslog protocol and provide a series
of seperate documents showing how it is used over various transports (eg.
UDP, TCP, ssh, etc.)

- A document will be produced that describes how syslog works, its
  architecture, relaying, security issues, plans going forward, etc.
  Information in RFC 3164 will form he basis of this document.

- A document will be produced that describes a modern syslog message
  format that is based upon what was presented in RFC 3164.  The
  message format in this document will be backward compatible with
  RFC 3164.

- A document will be produced that describes a standardized (plain)
  UDP transport for modern modern syslog messages. (i.e. syslog/udp)

- A document will be produced that describes a standardized (plain)
  TCP transport for syslog messages. (i.e. syslog/tcp)

- A document will be produced that describes transporting moden
  syslog messages over <XYZ> for the purpose of secrecy and/or
  integrity.  (i.e. syslog/ssh)

- A document will be produced that describes a standardized mechanism
  to sign syslog messages to provide integrity checking and source
  authentication. (i.e. syslog-sign)

If in doing some of the above we place the format of some vendor
messages (such as netscreen) outside of that documented and accepted
by the IETF then so be it.  We should not be about trying to come up
with something that we can shoehorn everything that exists into but
rather something that makes good technical sense.  If a vendor ends
up with a format in existing products that doesn't interoperate, so
be it.  They've have to issue a patch if they want to comply.

Darren

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 26 Nov 2005 10:23:15 +0100

Based on the discussions of the past few days, the one detail that I would add
to the charter is about <PRI> and backward compatability, something along the
lines of

While compatability with existing syslog systems is desirable, research shows
that these are so diverse that there is nothing in common amongst them apart
from <PRI> so that whilst that field will be retained, other fields may not be.

added to the paragraph on syslog protocol.

And yes, IESG and the ietf list will doubtless want to know why we regard that
as acceptable.

Tom Petch

---

From: Darren Reed <[email-masked]>
Date: Sat, 26 Nov 2005 22:39:26 +1100 (EST)

[ Charset ISO-8859-1 unsupported, converting... ]
> added to the paragraph on syslog protocol.

Why ?  The charter shouldn't be mentioning any specifics of the protocol(s)
that the group intends to work on.  The charter should be as relatively
open ended as possible with respect to the actual specifics delivered.

Darren

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 26 Nov 2005 21:22:48 +0100

----- Original Message -----
From: "Darren Reed" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: "Chris Lonvick" <[email-masked]>; <[email-masked]>
Sent: Saturday, November 26, 2005 12:39 PM
Subject: Re: [Syslog] Revised proposed charter

> open ended as possible with respect to the actual specifics delivered.

I see it the other way round.  If the charter can be specific, it should be, to
keep the subsequent discussion focussed on the more contentious areas.  Based on
the
post-Vancouver discussion, I see no alternative to including <PRI> and if that
is the case, then we should nail that down now.

I am, implicitly, agreeing with Rainer's list of 10 items; if we can agree a
charter, then the items he says need discussing are the ones we then focus on,
leaving the rest of -15 unchanged..

Tom Petch

---

From: Darren Reed <[email-masked]>
Date: Sun, 27 Nov 2005 11:54:37 +1100 (EST)

> I see it the other way round.  If the charter can be specific, it should
> be, to keep the subsequent discussion focussed on the more contentious
> areas.  Based on the > post-Vancouver discussion, I see no alternative
> to including <PRI> and if that is the case, then we should nail that
> down now.
> 
> I am, implicitly, agreeing with Rainer's list of 10 items; if we can
> agree a charter, then the items he says need discussing are the ones
> we then focus on, leaving the rest of -15 unchanged..

We don't re-charter every time that there is a disagreement on focus,
just when we need to change direction.  Tieing the charter down to
details will require us to change it when details change.

Darren