Subject: [Syslog] New direction and proposed charter

From: Chris Lonvick <[email-masked]>
Date: Mon, 21 Nov 2005 11:11:59 -0800 (PST)

Hi Folks,

I'd like for us to come to closure on some things.  I'm going to be a bit 
direct on these questions so we can focus quicker.  We really need for 
people to send in responses to see who's listening and involved.

>From the meeting, it sounds like we will get many more implementations if 
we continue to use <PRI>... at the start of syslog messages.  This will 
allow current receivers to continue to receive messages and put them in 
the right bins.  Does anyone disagree with this?

The WG has agreed to use the timestamp Rainer has in the current 
syslog-protocol.

Using the FQDN and numeric notations for IPv4 and IPv6 addresses has been 
agreed to.

Putting in the Structured Data still seems like a great evolutionary step 
for syslog.  I'd like to see that go into the new syslog-protocol.  Does 
anyone disagree with this?

Should we continue to have the MSGID in the header, or should that become 
an SD-ID element?

We've had slow-downs in our prior discussions about truncation and message 
length.  To complete this work without revisiting those discussions, and 
in the spirit of backwards compliance with traditional syslog, I propose 
that we accept the length as Rainer has proposed in syslog-protocol, and 
disallow any device to truncate the messages.  At some future time, 
someone can augment the syslog-protocol standard and define a mechanism 
and signalling that will allow truncation.  Does anyone disagree with 
this?

Encoding has been discussed and we have agreed upon US-ASCII and UTF-8 in 
appropriate places.  Could we add a language tag as an element in an 
SD-ID to indicate the language of the MSG?

We need a version.  Should that be in the header (after <PRI>), or as an 
element in an SD-ID?

One possibility would be to assemble a syslog message as:

<PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG

If we can agree to this then I suspect that we can have a working document 
within Rainer's timeframe.  I'll propose the following charter to keep us 
focused.

-------- 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 of the existing syslog mechanism while not breaking
backwards compatibility.  The most obvious problems that need to be
addressed in the syslog protocol are the timestamp, which has not
formally included a means to indicate the year, and the identification
of the source which has been a hostname without a qualified domain
name.  Additionally, a version, some type of message indicator, and a 
means to convey structured data will be included in the protocol.

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 standard will be produced that formally documents the syslog
protocol.  A mechanism will also be defined in this specification
that will provide a means to convey structured data.

- A standard will be produced that documents the UDP transport for
syslog.

- A standard will be produced that documents a mechanism to sign
syslog messages to provide integrity checking and source
authentication.

- A MIB definition for syslog will be produced.

-------------------------------------------

PLEASE review this and respond.

Thanks,
Chris

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 21 Nov 2005 18:21:24 -0500

Hi,

I am concerned about the emphasis on backwards compatibility. The
reason people want a standard is that existing server implementations
have made different design decisions, and device and application
vendors are forced to either interoperate with one vendor-specific
server implementation, or need to write code to support different
server implementations. Device and application vendors would like one
consistent solution that is vendor-neutral so their implementations
will interoperate with any standard-compliant server. 

If we strive for backwards compatibility, we will end up with a
standard that simply rubber-stamps many of the non-interoperable,
vendor-specific existing server implementations.  We should be
striving to produce a standard for syslog that is vendor-neutral and
that helps server and equipment/application vendors produce
interoperable implementations using one standard syslog specification.

I am, however, a strong believer in making it fairly easy for vendors
to migrate from their existing vendor-specific non-interoperable
implementations to a vendor-neutral interoperable standard, and to
make it possible for servers and senders to support both the existing
syslog and the new standard for syslog. 

I believe we should emphasize "ease of migration and co-existence"
rather than "backwards compatibility".

I suggest changing 
"The goal of this working group is to address the security and
integrity problems of the existing syslog mechanism while not breaking
backwards compatibility."
To
"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."

Some charter items could be interpreted as documenting existing
practices, rather than documenting an agreed-to standardized approach
for these aspects of syslog.

I suggest changing

> syslog messages to provide integrity checking and source

To
"
- 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."

David Harrington
[email-masked]

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 22 Nov 2005 06:57:21 -0800 (PST)

David,

I think your words have cut through the confusion on this.  I agree with 
your proposed changes.

Many thanks,
Chris

---

From: Darren Reed <[email-masked]>
Date: Wed, 23 Nov 2005 03:47:39 +1100 (EST)

> I think your words have cut through the confusion on this.  I agree with 

For what it's worth, I also agree with these proposed changes.

Darren
(on the road again for a few weeks)

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 22 Nov 2005 17:06:24 +0100

MSGID in the header is what I most want to see (and I believe that a well chosen
message id
makes an application field redundant)

total backward compatability is too much a bar to progress (as dbh says).

<PRI> is worth it if it increases the number of implementations (not because it
does or does not affect backward compatability)

internationalisation is a big can of worms; I think specifying UTF8 as we have
done is as far as we should go

otherwise, no strong disagreements

Tom Petch

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Wed, 23 Nov 2005 21:39:06 +0900

Chris/Rainer,

> the right bins.  Does anyone disagree with this?

Complete agreement.
> The WG has agreed to use the timestamp Rainer has in the current
In principle I agree with the timestamp format. It is good.
I may have missed the discussion on this matter,  in that case please
accept my apologies and ignore the rest of the mail.

To get existing BSD syslog devices specifically relays into the compatibility
fold it WILL be good idea to keep the timestamp in two parts

       RainerTimestamp =  BSD_syslog_timestamp  + RemainderTimestamp

> <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG

In the context of what has been said above about the timestamp. I would
suggest
  <PRI>BSD_syslog_timestamp FQDN VERSION MSGID Remainder_Timestamp [SD-ID]s MSG

That would allow existing BSD-syslog relays to handle the new syslog protocol
in a transparent manner. Everything from VERSION to the end is treated as "message".

We do not lose information.
     The Remainder_timestamp carries it - in a slightly less convenient place
     though.

On the other hand if we insist on using RainerTimestamp, existing BSD_syslog
relays will relay the message as

<PRI>BSD_syslog_timestamp FQDN RainerTimestamp FQDN VERSION MSGID [SD-ID]s MSG

The message does get distorted to some extent.

> If we can agree to this then I suspect that we can have a working
> document within Rainer's timeframe.  I'll propose the following charter
> to keep us focused.
> 

Glenn