Subject: RE: [Syslog] New direction and proposed charter

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 21 Nov 2005 21:12:16 +0100

Chris & WG 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Monday, November 21, 2005 8:12 PM
> To: [email-masked]
> Subject: [Syslog] New direction and proposed charter
> 
> 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.

I am also quite directly...

> 
> 
> 
> >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?

Yes, disagreement here. For the reasons outline in mail from Friday,
this is *NOT* true. Existing syslog receivers will be broken if we just
stick with <PRI> and do not adjust the other header fields.

Of course, it is doable. For details, review

http://www.mail-archive.com/syslog%40lists.ietf.org/msg00121.html 

(around the middle of the post).

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

See implications noted in previous mail quoted above.

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

See implications noted in previous mail quoted above.

> 
> 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?
> 

Agree, even does not hurt existing receivers.

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

Both is doable. If we want to stick as compatible as possible, it should
go into 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?

It's problematic. Syslog-protocol has no actual upper limit. Some
(useful) applications need more than 2K - that was the sense of the
compromise. So it is possible that a message gets truncated. However, we
could accept that fact without specifying a header for it. That could go
into a SD-ID, too.

> 
> 
> 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?

If so, we should include the *character set* not the language. In
respect to existing implementations, that would also be usefule. We
should strongly consider to allow (but not recommend) other encodings,
too (like popular JIS or EUC). I also posted this in my previous mail.

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

Header breaks backward-compatibility. SD-ID makes it chatty. In general,
if we try to keep backwards-compatible, we should do it "right" and be
able to handle the situation without the need of a version. Well... It
could still be an optional SD-ID.

> 
> One possibility would be to assemble a syslog message as:
> 
> <PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG
> 

I object this. It is smaller than protocol-15, but does not address the
backwards compatibility issue. If we go with that we can go with
-protocol-15, too.

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

We need to address the backward compatibility issues if we want to have
backward compatibility. Else we have the same problem again, just with
another header.

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

I think that would be a practical charter, given this is the consensus.

> 
> 
> PLEASE review this and respond.
> 
> Thanks,
> Chris
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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

---

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

Hi Rainer and all,

>From my perspective, I think that having a syslog receiver receive the 
message and get it into the right bin is acceptable.  If we don't have 
that then we are breaking very much.  If we can accomplish that, then 
receivers will continue to receive the messages and the parsers will have 
to be updated.

I believe that the alternative that you're saying, Rainer, is that syslog 
transmitters COULD keep their existing headers and our Working Group only 
put things in there.  If we go with that, then the parsers will still need 
to be updated to understand the SD-ID information.  I'd prefer to just 
keep the <PRI> and modify the rest of the packet.

We need to hear from more people on this.

Thanks,
Chris