RE: [Syslog] Revised proposed charter
Hi, I will observe that the syslog MIB has been declared "dead" in the ID-tracker, and it has expired in the I-D repository. Is this deliberate, and if so, why? No explanation is given in the ID-tracker. dbh. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Glenn > Mansfield Keeni > Sent: Thursday, November 24, 2005 5:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Revised proposed charter > > 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: > > 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 > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
Hi, It would be a good thing to enumerate in the charter the select set of mechanisms to be standardized and included in the charter deliverables by the charter deadlines. That would severely limit any possibility of mission creep, something this group needs to constrain. I am concerned about the lack of commonality in the existing implementations and the difficulty which that presents to reaching consensus. I suggest that it would be useful to agree on the order of message elements and to work from the front of the message to the back, in order, so that if item #5 becomes problematic, at least #1 through #4 can be standardized by the deadline, with #5 remaining implementation-specific, and then the WG can recharter to resolve #5 in a manner compatible with the #1 through #4 standardized message parts. David Harrington [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Anton > Okmianski (aokmians) > Sent: Wednesday, November 23, 2005 12:29 PM > To: Chris Lonvick (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Revised proposed charter > > Chris: > > This is fine, but does not include all the other specific > details we agreed on and as such is not different from what > we had before. I think we can focus our efforts better by > creating narrower scope. How about limiting backwards > compatibility to only. Requiring standardization of > better time stamp. Support for FQDN, IPv6. MSGID. > Internationalization (UTF-8). Etc... I am afraid that if we > leave the charter open-ended as before, we will be debating > the charter again 2 years from now. > > Also, sorry if I missed some earlier discussions on signing > messages. Proposed charter mentions source authentication. > For TCP mappings (such as BEEP), TLS already provides > authentication and encryption. SSH transport would provide > similar facilities. Is there an overlap here? Is message > signing targeted at just UDP transport? > > Thanks, > Anton. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Chris > > Lonvick (clonvick) > > Sent: Wednesday, November 23, 2005 12:05 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Revised proposed charter > > > > 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 > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
I support this clarification. Anton. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Petch > Sent: Saturday, November 26, 2005 4:23 AM > To: Chris Lonvick (clonvick); [EMAIL PROTECTED] > Subject: Re: [Syslog] Revised proposed charter > > Based on the discussions of the past few days, the one detail > that I would add to the charter is about 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 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 > - Original Message - > From: "Chris Lonvick" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, November 23, 2005 6:05 PM > Subject: [Syslog] Revised proposed charter > > > > 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 > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
> 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 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 ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
- Original Message - From: "Darren Reed" <[EMAIL PROTECTED]> To: "Tom Petch" <[EMAIL PROTECTED]> Cc: "Chris Lonvick" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, November 26, 2005 12:39 PM Subject: Re: [Syslog] Revised proposed charter > [ Charset ISO-8859-1 unsupported, converting... ] > > Based on the discussions of the past few days, the one detail that I would add > > to the charter is about 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 so that whilst that field will be retained, other fields may not > > be. > > > > 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 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 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 ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Why? Because the community implementing syslog protocol things seems to be ignoring what the group has been doing. This may be because they're unaware of the work or because it is being regarded as a "WTF?!" and doing their own thing. Most people seem to be ignoring 3195. Lets learn from that experience and try to develop something that'll be what people want to use rather than what we think they need. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
[ Charset ISO-8859-1 unsupported, converting... ] > Based on the discussions of the past few days, the one detail that I would add > to the charter is about 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 so that whilst that field will be retained, other fields may not > be. > > 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 ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Based on the discussions of the past few days, the one detail that I would add to the charter is about 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 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 - Original Message - From: "Chris Lonvick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 23, 2005 6:05 PM Subject: [Syslog] Revised proposed charter > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
- Original Message - From: "Darren Reed" <[EMAIL PROTECTED]> To: "Tom Petch" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, November 25, 2005 11:35 PM Subject: Re: [Syslog] Revised proposed charter > [ Charset ISO-8859-1 unsupported, converting... ] > > [tp] Strange, I was thiinking quite the opposite, that we had a fragile > > consensus which disappeared in > > Vancouver and has not been refound. Looking back at the messages posted > > in the past few days, about what should be in the header in what order, > > I was thinking, > > what now? because I see no consensus, rather the re-emergence of many > > different points of view. > > > > So while the proposed charter looks ok, because it does not go into that > > detail, I do not see how we progress any further, into the next level of > > technical detail, of what and how should be in the header. > > So long as everyone wants to solve every problem in one single RFC, > we will go nowhere. For those people I say "go use 3195" and stop > bothering the group with yoru quibbles. > > All this nonsense about NUL characters and message lengths, XML, > structured data, etc. Too many people here have a pet peeve they > want to see the first draft solve and seem determined to overload > it with that so that they're covered/happy. > > This is not a way forward but a way backward. > > We need to evolve the syslog protocol and we need to do that starting > with the basic protocol that has been used for years, build upon that > in a structured manner and conquer one piece of the problem at a time. > > If one thing is clear from this, it won't be possible to write a > single document that makes good all of the evolutions of the syslog > protocol. Some are going to have to be put in the "bad basket." > > If that happens to be yours, or mine, stiff. We're all going to > need to make sacrifices and changes if anything useful is going > to be achieved. > > Darren Mmmm I agree that sacrifices are needed but am puzzled by your reference to first draft. Syslog-protocol is at -15 and represents a (fragile) consensus about XML, null octet, truncation etc. What I don't understand is that Vancouver seems to say that we must reinstate - ok - and while we are at it, go back to square one on lots of other things. If that is how it is, so be it (but I am still puzzled). Tom Petch ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Chris, Let me have a go at rewriting the charter... > 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. 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. > 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. 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 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 ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
[ Charset ISO-8859-1 unsupported, converting... ] > [tp] Strange, I was thiinking quite the opposite, that we had a fragile > consensus which disappeared in > Vancouver and has not been refound. Looking back at the messages posted > in the past few days, about what should be in the header in what order, > I was thinking, > what now? because I see no consensus, rather the re-emergence of many > different points of view. > > So while the proposed charter looks ok, because it does not go into that > detail, I do not see how we progress any further, into the next level of > technical detail, of what and how should be in the header. So long as everyone wants to solve every problem in one single RFC, we will go nowhere. For those people I say "go use 3195" and stop bothering the group with yoru quibbles. All this nonsense about NUL characters and message lengths, XML, structured data, etc. Too many people here have a pet peeve they want to see the first draft solve and seem determined to overload it with that so that they're covered/happy. This is not a way forward but a way backward. We need to evolve the syslog protocol and we need to do that starting with the basic protocol that has been used for years, build upon that in a structured manner and conquer one piece of the problem at a time. If one thing is clear from this, it won't be possible to write a single document that makes good all of the evolutions of the syslog protocol. Some are going to have to be put in the "bad basket." If that happens to be yours, or mine, stiff. We're all going to need to make sacrifices and changes if anything useful is going to be achieved. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
Tom Petch - Original Message - From: "Alexander Clemm (alex)" <[EMAIL PROTECTED]> To: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]>; "Chris Lonvick (clonvick)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, November 23, 2005 6:50 PM Subject: RE: [Syslog] Revised proposed charter I think the charter looks good. It describes what the working group has to do and its deliverables. I agree that there is a next level of details that spells out the specifics of how to do it. We had a lot of discussion on this and seem to have come to a consensus, which is something that we should capture. [tp] Strange, I was thiinking quite the opposite, that we had a fragile consensus which disappeared in Vancouver and has not been refound. Looking back at the messages posted in the past few days, about what should be in the header in what order, I was thinking, what now? because I see no consensus, rather the re-emergence of many different points of view. So while the proposed charter looks ok, because it does not go into that detail, I do not see how we progress any further, into the next level of technical detail, of what and how should be in the header. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
MIB was Re: [Syslog] Revised proposed charter
Chris I was not, am not, quite clear what you are asking for but I am an SNMP expert and do review MIBs and was planning to do so for the syslog MIB as and when the protocol that the MIB is of is stable. (Be warned, when I commit to do something, I tend to avoid committing to a date and vice versa:-) I would expect a MIB to be required of us by IESG unless we can put up a very strong case why not. Tom Petch - Original Message - From: "Chris Lonvick" <[EMAIL PROTECTED]> To: "Rainer Gerhards" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 24, 2005 5:42 PM Subject: RE: [Syslog] Revised proposed charter > > OK - sorry 'bout that. > > Glenn - please update it and get it into the ID repository. > > All - who will commit to reviewing this document? I will need someone to > commit to this before I put it into the proposed charter. > > Thanks, > Chris > > On Thu, 24 Nov 2005, Rainer Gerhards wrote: > > > Oops, I have overlooked that one. I agree with Glenn that this should be > > in the charter. > > > > Rainer > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Glenn > >> Mansfield Keeni > >> Sent: Thursday, November 24, 2005 11:33 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [Syslog] Revised proposed charter > >> > >> 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: > >>> 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 > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> > >> > >> ___ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > ___ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
> Hi, > > OK - sorry 'bout that. > > Glenn - please update it and get it into the ID repository. > > All - who will commit to reviewing this document? I will > need someone to > commit to this before I put it into the proposed charter. I can look at the syslog side of it, but I am far from being an SNMP expert. I think we need at least one such expert to review it. So count' me as half a volunteer ;) Rainer > > Thanks, > Chris > > > > On Thu, 24 Nov 2005, Rainer Gerhards wrote: > > > Oops, I have overlooked that one. I agree with Glenn that > this should be > > in the charter. > > > > Rainer > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Glenn > >> Mansfield Keeni > >> Sent: Thursday, November 24, 2005 11:33 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [Syslog] Revised proposed charter > >> > >> 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: > >>> 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 > >>> Syslog@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > >> > >> > >> > >> ___ > >> Syslog mailing list > >> Syslog@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > ___ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
Hi, OK - sorry 'bout that. Glenn - please update it and get it into the ID repository. All - who will commit to reviewing this document? I will need someone to commit to this before I put it into the proposed charter. Thanks, Chris On Thu, 24 Nov 2005, Rainer Gerhards wrote: Oops, I have overlooked that one. I agree with Glenn that this should be in the charter. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Mansfield Keeni Sent: Thursday, November 24, 2005 11:33 AM To: [EMAIL PROTECTED] Subject: Re: [Syslog] Revised proposed charter 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: 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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
Oops, I have overlooked that one. I agree with Glenn that this should be in the charter. Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Glenn > Mansfield Keeni > Sent: Thursday, November 24, 2005 11:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] Revised proposed charter > > 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: > > 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 > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > ___ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Revised proposed charter
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: > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
I think the charter looks good. It describes what the working group has to do and its deliverables. I agree that there is a next level of details that spells out the specifics of how to do it. We had a lot of discussion on this and seem to have come to a consensus, which is something that we should capture. However, the question is if that next level (the "how" in addition to the "what") really belongs in a charter - not sure if the charter would be the right place. -- Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, November 23, 2005 9:29 AM To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] Revised proposed charter Chris: This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope. How about limiting backwards compatibility to only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now. Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption. SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport? Thanks, Anton. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > (clonvick) > Sent: Wednesday, November 23, 2005 12:05 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Revised proposed charter > > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
> Also, sorry if I missed some earlier discussions on signing > messages. Proposed charter mentions source authentication. > For TCP mappings (such as BEEP), TLS already provides > authentication and encryption. SSH transport would provide > similar facilities. Is there an overlap here? Is message > signing targeted at just UDP transport? Signing - as I understand syslog-sign - goes beyong that. You could also say it serves a different purpose. -sign is about signature inside the messages that you can use to verify the correctness not only in transit but also years later in an offline copy. The details are not 100% technically correct, but I think it conveys the overall idea. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
Chris: This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope. How about limiting backwards compatibility to only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now. Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption. SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport? Thanks, Anton. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris > Lonvick (clonvick) > Sent: Wednesday, November 23, 2005 12:05 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Revised proposed charter > > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
I fully agreee. Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > Sent: Wednesday, November 23, 2005 6:05 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Revised proposed charter > > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
