RE: [Syslog] Documenting the configuration of syslog
Hi all, I came across this discussion: http://groups.google.com/group/linux.debian.devel/msg/a35cfe80eeac3c3d There seems to be a valid point/demand in standardizing rsyslog.conf format, even though it has limited power. I thought I share the link. Rainer -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 12:09 PM To: David Harrington; 'Chris Lonvick' Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Documenting the configuration of syslog I too have looked at proprietary syslog MIB modules and have noticed how much simpler they are. For myself, the essential part of a syslog MIB is the statistics and that only for the device in which it resides. I would not throw away the other parts of the current MIB module, just make the COMPLIANCE optional. Tom Petch - Original Message - From: David Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED]; 'Chris Lonvick' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 11:58 PM Subject: RE: [Syslog] Documenting the configuration of syslog Hi, [as contributor] Traditionally, standards are based on some level of agreement across multiple implementations about what should be standardized. I have looked at syslog MIB modules from multiple vendors and have not found any that model the same concepts that the current syslog MIB models. Our current Devcice MIB is about configuring and monitoring the applications that use syslog. I have concerns about having this WG produce a MIB module that nobody seems to want. The industry doesn't seem to have rough consensus that this is the MIB that is needed. Vendor-specific MIB modules seems to focus on one of two approaches towards monitoring syslog activity - modeling a single syslog daemon, or capturing syslog messages in a MIB table so the logged information can also be accessed via SNMP. My limited research indicates that syslog.conf is the defacto standard for configuration of syslog. I wonder if there is enough similarity between vendors to develop a standard for those aspects related to the work of this WG. dbh ___ 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] transport-tls-11 review
Hi Miao, a few comments, rest snipped... Section 1.1: shouldn't it simply refer to -protocol for terms defined there? I think it makes it more consistent. Agree, so we should only leave TLS client and TLS server to be define in Syslog/TLS darft, right? That is my suggestion... Section 4.2: === Authentication in this specification means that the recipient of a certificate must actually validate the certificate rather than just accept a certificate. === Is this must intentionally in lower case? If so, is this plausible? Yes, intentionally. IMHO it is confusing if you use must in a non-normative way. If I were to implement it (and did not know about this discussion), I'd wonder if I MUST validate ... or if the must is a suggestion, like a SHOULD. Why not use SHOULD in the first place? Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] transport-tls-11 review
Hi all, I reviewed tls-11 today. Some notes: Section 1.1: shouldn't it simply refer to -protocol for terms defined there? I think it makes it more consistent. Section 4.2: === Authentication in this specification means that the recipient of a certificate must actually validate the certificate rather than just accept a certificate. === Is this must intentionally in lower case? If so, is this plausible? Section 4.3.1: typo tranport Section 5.1: === The server MUST be implemented to support certificate and certificate generation, === I do not think it is a MUST that a server must contain code to generate certificates. This should be left to the implementation. There is already the requirement to use certificates, so IMHO it is not the business of an IETF document to specify how they are provided. For example, I would provide a helper app with my syslog implementations, but not include it in the core app - it doesn't belong there. Other than that, I find the draft is quite acceptable. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Change between syslog-protocol 21 and 23 breaks UTF-8security
Sam, your proposed text is fine with me. So from my side, please go ahead. Thanks for your help, Rainer -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 7:36 PM To: Chris Lonvick Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Syslog] Change between syslog-protocol 21 and 23 breaks UTF-8security If the WG is OK with my proposed text, I'll handle it in an rfc editor note ___ 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] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd)
Hi folks, I am sorry for the long silence. I was extremely busy with projects and have to admit will be more or less unavailable for the next 3 weeks. Beginning of September things will finally clear up and I hope to be able to publish a new, hopefully final, version of -protocol. Even though I was not directly active in regard to -protocol, I thought about this requirement here. I have a somewhat weak text to propose: --- In any implementation, a situation can arise in which an originator or relay would need to block sending messages. A common case is when an internal queue is full. This might happen due to rate-limiting or slow performance of the syslog application. In such cases, it is RECOMMENDED that the originator or relay drops messages of lower severity in favor of higher severity messages. Messages with a numerically lower SEVERITY value have a higher severity than those with a numerically higher one. To-be-dropped messages SHOULD simply be discarded. The syslog application may notify a collector or relay about the fact that it drops messages. If the underlying protocol supports congestion control, discarding of messages SHOULD be avoided. --- I have blogged about why I think this is the right thing to do, you may view the details of my thoughts here (sorry, I'd like not to duplicate text as I am already very short on time): http://rgerhards.blogspot.com/2007/08/on-reliability-and-need-to-discard _13.html I would appreciate comments and, even better, improvements to the proposed text. I may not be able to reply immediately, but I will definitely appreciate any comment and incorporate it. Sorry once again for the long silence. Rainer -Original Message- From: Anton Okmyanskiy (aokmians) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 7:32 PM To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstioncontrol (fwd) Chris: Can we ask Mangus to provide suggested text? He mentioned it is just a paragraph. This would make it a bit easier to get to the point of what/how he wants addressed and evaluate if we agree with it. If his suggested text is not too demanding on implementations, but rather a recommendation, it is easier to accept it. Is he now concerned with syslog reliability (dropping of arbitrary messages due to congestion and queue overfill) instead of previously raised concern of syslog being a bad citizen and causing congestion for others? For end-to-end reliability, we have a whole section describing many aspects we did not intend to address in UDP draft. Why is there an assumption of blocking application? Maybe my syslog application writes messages to file first, returns to client app and then asynchronously transmits them while listening for ICMP errors. I also don't think we intended to cover any end-to-end guarantees from application perspective. Even reliable network transport (TCP) does not means reliable application-to-application delivery. We had the app-level-ack discussion and dismissed it. So, yes, messages are not guaranteed to be delivered to their final destination and processed there. They can be dropped, they can get corrupted, receiver may crash right after getting message but before processing it, relay may fail, etc. Thanks, Anton. -Original Message- From: Chris Lonvick (clonvick) Sent: Wednesday, July 11, 2007 7:16 AM To: [EMAIL PROTECTED] Subject: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Hi Folks, Here is clarification of what Magnus wants. We have so far received Eliot's proposal but I don't think that addresses the concern. I would like to hear from everyone. Do we want to push back on Magnus, or can someone propose some text around this? Thanks, Chris -- Forwarded message -- Date: Fri, 06 Jul 2007 18:08:12 +0200 From: Magnus Westerlund [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED] Cc: Chris Lonvick [EMAIL PROTECTED], Lars Eggert [EMAIL PROTECTED] Subject: Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd) Hi David, I think you are missunderstanding things here. But thanks for protesting and not accepting crap. But let me make clear what I actually think is needed in regards to syslog to make it a working protocol to deploy. First, this starts as an issue with TLS over TCP and the syslog base protocol. It can also arise teorethically for UDP, but as I understand not in practice for todays usage. When you are using TCP, in case the syslog sender generates events at an rate that is higher than available rate over the path used there will be build up of a queue. So I would like to have some words somewhere saying what you do when you build up a queue of messages that should be transmitted, but the queue simply keeps growing. What do I do? To me this
RE: [Syslog] Discuss - UDP Checksum
[Strictly speaking as an implementor, not as a draft editor] I second Juergen's point of view. I go even further. When receiving, I take great care not to loose any message. Under stress conditions (e.g. low system memory), I accept lage deformations of the message. Checksums are my least concern and I wouldn't discard a message just because the checksum is invalid. I will defintely ignore any such MUST in a RFC, at least by default. I may, however, flag this message as being in error (which possibly means it ends up in a different bin). The reasoning behind all this is that a vital message might be lost forever and it is better to receive it in some degraded state. At least this is what my *actual* users are requesting. Rainer -Original Message- From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 9:24 PM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Discuss - UDP Checksum On Thu, Jul 05, 2007 at 11:51:13AM -0700, Chris Lonvick wrote: Which brings us back to our original question. Is the proposed language below what the WG wants? As an implementor, I have a problem with the statement syslog senders MUST use UDP checksums when sending messages over IPv4 since on several platforms, I simply can't ensure this when I write a portable SYSLOG implementation. So I can either claim my code to be RFC compliant while in a real deployment it might not behave conforming to the RFC (depending on the kernel settings for example), or I tell the truth that I can never guarantee compliant behaviour of my implementation. So if we need to have language at all, what about syslog senders MUST NOT disable UDP checksums This is something I can implement much more easily since the default seems to be enabled on those platforms I am familiar with. ;-) Or alternatively go back to SHOULD syslog senders SHOULD use UDP checksums when sending messages over IPv4 with the likely non-obvious interpretation that you should enable / not disable checksums in your code but if the kernel bites you, you are still fine. My point is that if we put out requirements for implementations, lets do this in a way that a coder can reasonably implement them. /js [No, I am not implementing SYSLOG right now - but I am familiar with other protocols running over UDP and hence this got my attention.] -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ 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] draft-ietf-syslog-protocol-21.txt: section 3containsnewtext to address ietf last call comments (fwd)
I have been a bit brief. MSG is passed in via the POSIX API. So the actual generator of MSG is not syslogd. However, and you are right on this, from the on the wire IETF point of view, both are generated by the same entity, that being syslogd. Rainer -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 9:59 AM To: Glenn M. Keeni; [EMAIL PROTECTED] Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3containsnewtext to address ietf last call comments (fwd) I agree that it is a point of view. I do not see the necessity of the two layers for MSG and SYSLOG-MSG as a part of operations and management. The reason being that it will generally be the same entity (application, module call it whatever) that will generate MSG and SYSLOG-MSG. Unix *nix, these are always two different entities. Rainer ___ 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] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd)
I agree that it is a point of view. I do not see the necessity of the two layers for MSG and SYSLOG-MSG as a part of operations and management. The reason being that it will generally be the same entity (application, module call it whatever) that will generate MSG and SYSLOG-MSG. Unix *nix, these are always two different entities. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd)
Glenn, OK, it looks like we get to the root of the issue: our understanding of facility is fundamentally different. You assume that facility is indeed a semantic entity that uniquely identifies an originator (that part of the system, that originally generates the MSG content). I do not understand how this can work. Can you please explain to me how a set of only 24 different values is able to uniquely identify application classes? In a practical example, can you please explain me which facilities must be used by these originators (randomly selected): - http daemon - dns daemon - firewalls - scp daemon - ssh daemon - SIP gateways - network cache servers - routers - switches Thanks, Rainer -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Sunday, June 24, 2007 1:21 AM To: Rainer Gerhards Cc: tom.petch; [EMAIL PROTECTED] Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) Rainer, Rainer Gerhards wrote: Glenn, -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Saturday, June 23, 2007 2:45 AM To: tom.petch Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) Tom, I do understand the line of reasoning. But I do not agree with the conclusion. I agree that if we follow the ABNF we can have layers. [It does not limit us to three layers]. But a reality check says that we can have at most 2 significant layers. Significant from the point of view of operations and management. Facilities will just generate SYSLOG-MSG. Facilities do not generate anything. A facility is a number in the range 0..23 - that's it. Originators generate messages. No. Facility is not a number. Perhaps the number or value that you are referring to is an encoding of the facility. rfc3164 and later draft-ietf-syslog-protocol-21.txt Table 1. gives the mapping between the numerical codes and corresponding Facility :-) But let us not split hairs. Given that we have three layers it will be useful to have a reality check by mapping these layers to entities that we have defined or know about. I am afraid we keep going round in loops because of the lack of precise definitions. Without these definitions it is very difficult to tell who is going wrong where. The terms and entities we know understand in this context are Facility , Transport. Who generates the MSG? An originator. But the MSG ( or content) is already present before the originator (syslog application). This is wrong. It just does not fit the layer mechanism. Is that a new entity that we are defining? No What real world entity does it map to ? Syslogd Syslogd is a syslog application ? Then it is in layer 2. We do not have a mapping for layer 1 - content. Why are we interested in its operations ? To detect problems and get performance stats (from a mib perspective). Yeah. It appears that we do not have a specific interest in its operations. An example of a specific interest in syslog application statistics would be how many Kernel messages are generated hourly or how many Kernel messages with severity code = 'Error' are generated hourly. The answer to the last question will determine the significance of the entity and the corresponding layer. I am sorry if the above sounds like a digression, but I have a real problem in mapping onto reality without answers to the above. Please note that there are actually more than three layers in the real world. See I will not try to argue about that. We can have any number of layers. But whether all of them are significant or not is the question. That is what we are trying to ascertain. [STUFF DELETED] I think that the existing, already agreeed text in protocol-21 does give us a three way split in the stack. Looking at the ABNF, there is MSG which is prepended by additional fields to form SYSLOG-MSG which will in turn be prepended before the PDU is placed on the wire. So I can see a top layer generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and a lower layer providing the UDP/TLS/etc headers/trailers. In turn, this can drive statistics and error counters, so that a single MSG which is sent with two different facility codes each over three transports would count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an invalid facility would increment an error counter in the middle layer. I am not saying this is the only split or the best split and I am certainly not saying any implementation has to make any of this layering apparent in its code structure; but I do think that a three-way split is sensible. I will not argue. But, I will repeat, who sends the MSG, to whom ? Facilty to X ? X
RE: [Syslog] -syslog-tc-mib Facilities
Glen, it is b). I think you are assuming way too much about severity. It's a field with only 24 different values. It is *not* something like an IP port. You cannot reliably say anything on reception of a specific facility. OK, LOG_KERN and LOG_MAIL are almost always what they claim to be. But I wouldn't trust LOG_UUCP these days. And what is the distinction between LOG_AUTH and LOG_AUTH2 (in a consistent way)? What should a HTTP daemon log to? There is no LOG_HTTP. Maybe, if we save these 4 values, we can define one. But would that really help? The concept of identifying something based on these poor 24 values is crappy. Facility is a (bad) legacy. We tried to make it useful by increasing it to an integer, but that has been rejected in 2005. The last draft actually describing facility in a useful way was http://tools.ietf.org/id/draft-ietf-syslog-protocol-15.txt Here is the relevant text: ### 6.2.2. FACILITY FACILITY is an integer in the range from 0 to 2147483647. It can be used for filtering by the receiver. It is a category, allowing a coarse grouping of messages. There exist some traditional FACILITY code semantics for the codes in the range from 0 to 23. These semantics are not closely followed by all senders, and practice has shown that common semantics for message categories are hard to establish. Therefore, no specific semantics for FACILITY codes are specified or implied in this document. ### Re-read this part: *** practice has *** shown that common semantics for message categories are hard to *** establish. That's exactly what it is, especially if you only have 24 discrete values. All drafts after -16 simply copied the text from RFC 3164, because that was WG consensus (at the time of the year ;)) and it doesn't make sense to bother doing much with a field that is mostly useless anyhow. Rainer -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Saturday, June 23, 2007 7:36 AM To: Rainer Gerhards Cc: Chris Lonvick; [EMAIL PROTECTED] Subject: Re: [Syslog] -syslog-tc-mib Facilities Rainer, I did inot get the point. Why do we have to stick to only the facilities that are used on all platforms? Is it that a. all system do not use the facility codes? e.g. system A uses facility code 12 for ntp while system B uses nothing or, localuse facility code for ntp, or, b. all systems do not have the same semantics for the facility codes ? e.g. system A uses facility code 12 for ntp while system B uses facility code 12 for kernel etc. Glenn Rainer Gerhards wrote: The discussion came up about the use of the Facilities in the -syslog-tc-mib document; are they normative or non-normative. David and I discussed this and have concluded that they are normative to the version of the protocol that we are now discussing. That may be changed in the future but we can't predict that. However, the fact remains that the Facility really can't always pinpoint the source of the content of the message. Then on page 5 of syslogMIB-TC the statement Facility and Severity values are not normative but often used. will need to be deleted - is that correct ? Yes, that would need to be deleted. However, we should then stick with only the facilities that are used on all platforms. ntp (12),-- NTP subsystem messages logAudit(13),-- log audit messages logAlert(14),-- log alert messages cron2 (15),-- clock daemon messages Are note universal. See this excerpt from the current glibc syslog.h: ### /* facility codes */ #define LOG_KERN(03) /* kernel messages */ #define LOG_USER(13) /* random user-level messages */ #define LOG_MAIL(23) /* mail system */ #define LOG_DAEMON (33) /* system daemons */ #define LOG_AUTH(43) /* security/authorization messages */ #define LOG_SYSLOG (53) /* messages generated internally by syslogd */ #define LOG_LPR (63) /* line printer subsystem */ #define LOG_NEWS(73) /* network news subsystem */ #define LOG_UUCP(83) /* UUCP subsystem */ #define LOG_CRON(93) /* clock daemon */ #define LOG_AUTHPRIV(103) /* security/authorization messages (private) */ #define LOG_FTP (113) /* ftp daemon */ /* other codes through 15 reserved for system use */ #define LOG_LOCAL0 (163) /* reserved for local use */ #define LOG_LOCAL1 (173) /* reserved for local use */ #define LOG_LOCAL2 (183) /* reserved for local use */ #define LOG_LOCAL3 (193) /* reserved for local use */ #define LOG_LOCAL4 (203) /* reserved for local use */ #define LOG_LOCAL5 (213) /* reserved for local use
RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd)
Glenn, -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Saturday, June 23, 2007 2:45 AM To: tom.petch Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnewtext to address ietf last call comments (fwd) Tom, I do understand the line of reasoning. But I do not agree with the conclusion. I agree that if we follow the ABNF we can have layers. [It does not limit us to three layers]. But a reality check says that we can have at most 2 significant layers. Significant from the point of view of operations and management. Facilities will just generate SYSLOG-MSG. Facilities do not generate anything. A facility is a number in the range 0..23 - that's it. Originators generate messages. Given that we have three layers it will be useful to have a reality check by mapping these layers to entities that we have defined or know about. I am afraid we keep going round in loops because of the lack of precise definitions. Without these definitions it is very difficult to tell who is going wrong where. The terms and entities we know understand in this context are Facility , Transport. Who generates the MSG? An originator. Is that a new entity that we are defining? No What real world entity does it map to ? Syslogd Why are we interested in its operations ? To detect problems and get performance stats (from a mib perspective). The answer to the last question will determine the significance of the entity and the corresponding layer. I am sorry if the above sounds like a digression, but I have a real problem in mapping onto reality without answers to the above. Please note that there are actually more than three layers in the real world. See http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph tml The text in this link was offered for inclusion in the draft, but it was objected as being not network-centric enough. As a result, -protcol-20 defined the 3 layers that we actually have from a network point of view: http://tools.ietf.org/id/draft-ietf-syslog-protocol-20.txt That was rejected as being to complex. So -21 went back to 2 layers and consequently needed to use very vague terms. The problem simply is that you cannot put the complexity of real-world syslog (and its POSIX API) into a two-layer network view. If you are forced to, you need to remove many subtleties. To use the terms from my precise architecture description: An -protocol-21 originator is a combination of a) PLOrig b) remote PLOrig c) PLGenerator d) PLGExt e) Message Router A relay is a combination of a) GWI b) GWO c) RelayEng d) RelayEngExt e) Message Router A collector is a combination of a) Store, Disc, ... b) CollectorEng c) CollectorEngExt d) Message Router As you can see, they have much in common. But you cannot precisely define them if you are not permitted to define them precisely - aka you get what you pay for ;) I think that the existing, already agreeed text in protocol-21 does give us a three way split in the stack. Looking at the ABNF, there is MSG which is prepended by additional fields to form SYSLOG-MSG which will in turn be prepended before the PDU is placed on the wire. So I can see a top layer generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and a lower layer providing the UDP/TLS/etc headers/trailers. In turn, this can drive statistics and error counters, so that a single MSG which is sent with two different facility codes each over three transports would count as 1 in the upper layer, 2 in the middle and 6 in the lower. Or an invalid facility would increment an error counter in the middle layer. I am not saying this is the only split or the best split and I am certainly not saying any implementation has to make any of this layering apparent in its code structure; but I do think that a three-way split is sensible. I will not argue. But, I will repeat, who sends the MSG, to whom ? Facilty to X ? X to Facility ? Facility to Facility ? If it one of the first two cases then, what is X ? Using Facility here is just plainly wrong. And what do you mean by send - this was a lengthy discussion. -protocol was forced to use send only for the technical term of putting messages on the wire. If so, than transport senders send to transport receivers. If you use send in a more logical, upper-layer view (which is prohibited for -protocol by WG consensus), then originators ultimately send to collectors. That's it. In precise real world terms: PLGenerators send to Collector Engines. And, yes, we are going in loops. It doesn't help that the WG always forgets what it requested the other day. Whatever definition you like - I am pretty sure, you'll find something in the 22 revisions of -protocol. I am tired of moving text from one revision into the new one, just to remove it the next time. Folks, lets get serious and remember what
RE: [Syslog] -syslog-tc-mib Facilities
The discussion came up about the use of the Facilities in the -syslog-tc-mib document; are they normative or non-normative. David and I discussed this and have concluded that they are normative to the version of the protocol that we are now discussing. That may be changed in the future but we can't predict that. However, the fact remains that the Facility really can't always pinpoint the source of the content of the message. Then on page 5 of syslogMIB-TC the statement Facility and Severity values are not normative but often used. will need to be deleted - is that correct ? Yes, that would need to be deleted. However, we should then stick with only the facilities that are used on all platforms. ntp (12),-- NTP subsystem messages logAudit(13),-- log audit messages logAlert(14),-- log alert messages cron2 (15),-- clock daemon messages Are note universal. See this excerpt from the current glibc syslog.h: ### /* facility codes */ #define LOG_KERN(03) /* kernel messages */ #define LOG_USER(13) /* random user-level messages */ #define LOG_MAIL(23) /* mail system */ #define LOG_DAEMON (33) /* system daemons */ #define LOG_AUTH(43) /* security/authorization messages */ #define LOG_SYSLOG (53) /* messages generated internally by syslogd */ #define LOG_LPR (63) /* line printer subsystem */ #define LOG_NEWS(73) /* network news subsystem */ #define LOG_UUCP(83) /* UUCP subsystem */ #define LOG_CRON(93) /* clock daemon */ #define LOG_AUTHPRIV(103) /* security/authorization messages (private) */ #define LOG_FTP (113) /* ftp daemon */ /* other codes through 15 reserved for system use */ #define LOG_LOCAL0 (163) /* reserved for local use */ #define LOG_LOCAL1 (173) /* reserved for local use */ #define LOG_LOCAL2 (183) /* reserved for local use */ #define LOG_LOCAL3 (193) /* reserved for local use */ #define LOG_LOCAL4 (203) /* reserved for local use */ #define LOG_LOCAL5 (213) /* reserved for local use */ #define LOG_LOCAL6 (223) /* reserved for local use */ #define LOG_LOCAL7 (233) /* reserved for local use */ ### When we claim to create normative names for facilities, we should not cause backward compatibility problems for those facilities that are not even mentioned in the relevant system header files. Claiming them would essentially eat up the remaining four extension possibilities. For example, I'd much more prefer to have a LOG_HTTP in the future than to have a LOG_CRON2... Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] draft-ietf-syslog-device-mib-15
Tom, I have documented the generic design of almost (all?) syslog implementations I know. Of course, there are some slight differences if you look at the code, but the logical functions are present. Find it here: http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph tml Rainer -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 1:52 PM To: syslog Cc: David Harrington Subject: [Syslog] draft-ietf-syslog-device-mib-15 A few more suggestions on this thorny matter:-( I like the change to [references] in the object descriptions - but I would suggest moving the paragraph which tells the RFC Editor what to do up the document to the first time that RFCPROT occurs. And label it as a Note to the RFC Ed. because that is what it is (unless we wait on the publication of the other RFC before submitting this one which could delay it for nine months) In the statistics entries, I suggest that 'should have a zero value' is more accurate than 'will have a zero value' (really it is 'SHOULD be zero' but I do not think that that is allowed in a MIB module). s2 'A relay forwards /some/ ... ' suggest /some or all/ s3 statistics now include received, sent, relayed and discarded so I would mention all those options here. SyslogRoles confuses me; I read the earlier text in s2 as sender/receiver being the lower layer and collector/relay/originator as being the application; in which case, I expect the Roles to be collector/relay/originator ie relay includes both sender and receiver in the lower layer sense in which they are used elsewhere. SyslogEncapsulation - what did we decide about Syslog-Sign; I have lost track. suggest removing --syslogControlTable -- -- --syslogOperationsTable -- syslogControlBindPort - might there be a default of 514? syslogOperationsMsgsTransmitted - I would prefer syslogOperationsMsgsSent since we talk elsewhere of Sender and not Transmitter. The two terms are near synonyms but could confuse a non-native speaker syslogOperationsMsgsDropped The number of messages that could not be queued for transmission by the syslog sender. I am unclear what this means; it sounds to me like an implementation detail. In general, I would expect there to be other reasons, other resource shortages, why messages could not be sent and would prefer a more generic description with 'could not be queued' as an eg rather than the sole cause syslogOperationsCounterDiscontinuityTime OBJECT-TYPE counters, viz., counters with OID prefix I would suggest Object Descriptor rather than OID prefix syslogOperationsMsgsMalFormed - the reference to s6.3 is a reference to structured data whereas the text in this I-D only talks of header; I know of no reference for malformed headers, although it has surfaced on the list, without, as I recall, any conclusion. Tom Petch ___ 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: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls
David, let me start with the relays: given the recent discussion, I think it would be much more advisible to add a few sentences to -protocol (I already made a proposal) that clarifies the situation. It is not much that needs to be added. It would resolve all those other issues. Regarding generic certificates, I do not see an overwhelming reason to have them (and I was one of them who liked them). I agree with Sam that there can be placed unique certificates on the device during the manufacturing process. Another story, however, is the need to authenticate/verify a device. Without any doubt, there is more than one scenario where authentication based on the device is mandatory. However, syslog is also often deployed in (low end) scenarios where the (part-time) operator is simply interested receiving log messages from his 5 or so routers. This admin is often not very knowledgable. If we now require that admin to either a) configure access rules for all (though few) devices or b) use unencrypted UDP syslog I am sure many of these admins will resort to b) because a) requires too much learning. In the essence, strong security/authentication would bring us less real-world security (pretty much the same thing with strong passwords ... so strong that they are stored on post-it notes under the keyboard). So I would not like to see client and server authentication to be a MUST. Well ... a MUST for an implementation to have that capability would be OK. But an admin must be capable to configure sender and/or receiver to work without authentication. No matter what we specify in -protocol, that capability will be available in all implementations that I foresee. IMHO an uncoditional MUST would create a false sense of security ... and the most insecure thing is false sense of security. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 5:14 PM To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; [EMAIL PROTECTED] Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog- transport-tls Hi WG, [speaking as co-chair] As co-chair, I will need to advise Miao to remove support for generic certificates unless there is overwhelming WG consensus to keep them, and the explanation of why reuse of private keys is necessary will need to be compelling. Please read RFC4107 (which is short). There are ambiguities in the TLS document regarding who MUST authenticate that will need to be tightened up. As the email from Tom reflects, part of the problem is the ambiguity in the definition of relay; I think it needs to be made clearer in the -protocol- document that a relay is a receiver and is a sender, and clearer in the -tls- document that authentication is hop-by-hop. Personally, I think we should make authentication more mandatory than is currently described, but the WG needs to reach such a consensus. If we keep the optional authentication(s), then the WG should justify in the document why it makes protocol sense for the authentication(s) to be optional. The WG needs to develop the table showing how the various authentication options mitigate threats, especially MITM threats, and we should have text that describes this as well. Please work with Miao to address these issues. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 12:53 PM To: Miao Fuyou; 'Sam Hartman'; [EMAIL PROTECTED] Subject: Relays was Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls inline Tom Petch - Original Message - From: Miao Fuyou [EMAIL PROTECTED] To: 'Sam Hartman' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 5:50 AM Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls Hi Sam, Thanks for the review! My response is inline. Regards, Miao -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 7:23 AM To: [EMAIL PROTECTED] Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls Hi, folks. I had no comments on the UDP draft or the main protocol draft so I have forwarded them to IETF last call. I do have some concerns with the TLS draft. snip Are senders and relays required to have a certificate and to use that certificate? It is not required, but it is preferrable for some deployment where malicious senders may send lots of messages to overwhelm the receiver. Sam I have a slightly different view. To quote the I-D, where it says The sender/relay should initiate a connection to the receiver I take that as the sender initiates a connection to the receiver if no relay is present or to the relay (when present), the relay (when present)
RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard
Mark == Mark Andrews [EMAIL PROTECTED] writes: [snip] Similarly if syslogd is using a reliable transport to talk to another syslogd. That too can block which will eventualy lead to blockages to applications / memory exhaustion. *That* is a different beast, not yet discussed. I know that it exists but it is not related to DNS. If it happens, it is really bad and typically results in a complete system hang. There are some situations where a lossy transport is preferable. For example, I have written a syslog/TCP implementation which, if forced to run in single-threaded mode, favours discarding messages over blocking as the later could indeed lead to fatal problems on a typical linux system. The root cause, however, is not reliable syslog per se. The root cause is the implementation. A reliable syslogd actually needs to be implemented with a non-blocking, de-coupled, buffered design. In almost all cases, that means separate receiver threads, a to-be-processed message queue and separate sender threads. Still, you have to decide what to do if the queue size is exhausted. But that scenario is much less likely. In that case, I'd still favour loosing some messages over potentially loosing all AND the system the syslogd runs on. As far as I see it, this is an app-layer issue out of scope for the underlying protocol. The problem, of course, is that syslog is simplex and hop-to-hop, so the original sender will never know that the message was lost. Protocol-wise, I do not see any fix to that except integrating some asynchronous notification mechanism. IMHO, this is outside the scope of syslog. It may be useful to add some hint to implementors pointing to this blocking condition. But I am not sure if it is really justified. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] An early last call comment on protocol-19
Sam, I need to check the mailing list archives and my notes, but I think there was no technical reason to use ISO instead of BCP 47. If I do not find anything, I'll simply change the reference. In any case, I'll post what I find out. Rainer -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 10:39 AM To: [EMAIL PROTECTED] Subject: [Syslog] An early last call comment on protocol-19 I failed to write this up yesterday. Your protocol document uses ISO language identifiers rather than BCP 47. Please either use BCP 47 or explain for all the language sets that BCP 47 can identify but your choice cannot why syslog implementations will not care. ___ 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] 3195bis before syslog-sign
-Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 11:46 AM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] 3195bis before syslog-sign Chris all, As you mentioned, Darren, Marshall, and I will produce an internet- draft that revises RFC 3195 (rfc3195bis). As part of that effort we envision accomplishing the following: * Obsoleting RAW and COOKED profiles. The RAW profile has a length limitation that we have been told is not appropriate for syslog-signed. The COOKED profile has seen no uptake. This dramatically simplifies the draft. * A new profile that has taken on the name of TARTARE will essentially be RAW rev 2. Messages sent with the TARTARE profile will conform to draft-ietf-syslog-protocol's syntax, and have no length limitation. I agree with Bazsi, multiple messages inside a single beep block need a different framing. The question is if we drop the multiple message per block capability. Beep framing is not inefficient per se... * We will review existing security considerations. For instance, RFC 3195 calls for use of 3DES for TLS. We propose that the new draft take on a more modern approach with regard to algorithm agility and which algorithm SHOULD be the low bar. In our early drafty draft, we were unable to eliminate all references to RFC 3164, due to reference of security considerations seemingly not covered in draft-ietf-syslog-protocol. However, those references that remain are NOT normative. If a complete separation for 3164 is desired we will need to incorporate a few of those remaining concerns, where IMHO the existing text in 3164 is sufficient. syslog-protocol had carried over all security considerations from RFC 3164. Those now missing have been removed because it was WG consensus that these are not valid security considerations. I suggest consulting the mailing list archive before mandating any of them. If we now find that something essential has been removed, we should add this to -protocol during IETF last call. This would be the place where it belongs. Finally, do people desire any other changes that would be considered necessary either for draft-ietf-syslog-protocol or for the forthcoming syslog-signed work? I will think about this, but out of my head I do not see any change I would desire. One thing that would potentially be useful is the transport path indication that was available with COOKED. However, I do not know of a single implementation (including mine) that acutally supports it - it was a very complicated beast. So it is probably not desirable to have it. Rainer We predict this work to progress rapidly. Thanks, Eliot Chris Lonvick wrote: Hi Folks, David Harrington and I had a talk about syslog-sign and its dependencies upon 3195bis. As was noted in the email discussion it would be messy to try to publish syslog-sign with dependencies upon 3195, then update 3195, then revise syslog-sign. We had a talk with Sam Hartman, our AD, who agreed that we should revise RFC 3195 to eliminate unnecessary dependencies. David and I are pleased to announce that Darren New, Marshall Rose and Eliot Lear have volunteered to produce a revision to RFC 3195. We expect that this will be a transport for syslog-protocol so that syslog-sign, and any other, future applications, can make use of syslog-protocol without having to worry about transport dependencies. Other goals of 3195bis will be to deal with the length limitation in a manner consistent with the other transports, and to eliminate references to RFC 3164. We've have had an initial explanation of how the authors will revise 3195 which sounds reasonable. I will let Darren, Marshall and Eliot propose the changes to the list. This should be a quick effort so please pay attention and discuss this on the list so we can get it moving. Thanks, Chris David ___ 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] 3195bis before syslog-sign
Hi John, -Original Message- From: Moehrke, John (GE Healthcare) [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 1:45 PM To: Eliot Lear; Chris Lonvick Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] 3195bis before syslog-sign The Healthcare industry has tried to use COOKED... WHY is it considered no uptake? We have security audit events that get captured in an XML message; thus COOKED would be preferred. (See RFC 3881) As you know, I value the work you are doing in IHE very much. I consider the IHE record a payload of the syslog message. So having the protocol itself XML-based does not neccesarily have any influence on IHE, as the payload is not directly related to it. On the issue of COOKED, I tend to agree that it has not received any vital interest. As you know, I have implemented it, too. My implementation, as I now know, seems to have some problems. I have not intended to fix them as I actually never received any real demand on that functionality. I had one interop conversation with someone working on an IHE project (a very smart guy, was nice talking to him). This is where I became aware of the problem with COOKED in my stack. One or two other folks asked about COOKED and I think some university project implemented it. But again, no real demand. Also, I do not know a single *complete* implementation of COOKED. In my previous reply, I talked about the PATH elements. In theory, these can be quite useful. But it is pain in the ... to generate and to track them. Nobody has done that. For IHE, keep in mind that you would need to implement PATH elements if you ever want to (really) claim compliance to 3195 (these are not optional, as far as I remember out of my head). As a last example, I have learned that Cisco has implemented 3195 (which is very welcome), but also only RAW. With RAW, we have at least some actual implementations, even though I have yet to see someone who deploys them. But they would work and would interoperate. So my personal conclusion, too, is that COOKED is no uptake. I like the idea of obsoleting it. That does not mean you can no longer use it. I question there is any specific value of COOKED for IHE. If it is done in the spirit of syslog-protocol, the IHE record needs to be encoded as sturctured data anyhow. So it does not matter if the underlying transport is XML-based or not. I agree that the audit servers have not implemented it, but then again there isn't much conformance to any other syslog specification either. I would like to understand why no uptake is a reason for removing this. It is not for lack of trying. As a very interested observer and consumer of your standards, I am getting very frustrated at the lack of commitment to ANY specification and lack of interest in completing anything. I strongly recommend singular focus on syslog-protocol and it's bindings. Get them implemented before you start messing around with other things. I had thought this was the agreement of the committee last year. Here I fully agree with you. I think, however, there is currently nothing we can do to help advancing -protocol and the transport mappings. They have been submited to the IESG and are now waiting for IESG attention. So the WG can either idle or do other things. As we know 3195 needs to be revised, I find it useful to think about that. Especially as I agree it should be straightforward activity. What is questionable is if it is right to old -sign once again for completion of other work. This has done many time, maybe too many times. On the other hand, there is good reasoning to do so and the chairs have explained their reasoning. I agree with their position. HOWEVER, as soon as new work items for -protocol and the transport mappings come up, we should immediately turn our attention to them. Being through thru 4 years (or were it 5?) of revisions of -protocol, I definitely want to see this work finished ASAP. I agree there is some danger in discussing things. If -protocol and mappings need attention, it might be problematic to switch back attention to them. I see this risk. Maybe it is important enough to actually do nothing but idling... I hope this clarifies my position. I honestly believe that the current discussion is useful and is also useful for IHE. Rainer John Moehrke GE Healthcare -Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 4:46 AM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] 3195bis before syslog-sign Chris all, As you mentioned, Darren, Marshall, and I will produce an internet-draft that revises RFC 3195 (rfc3195bis). As part of that effort we envision accomplishing the following: * Obsoleting RAW and COOKED profiles. The RAW profile has a length limitation that we have been told is not appropriate for syslog-signed. The COOKED profile has seen no uptake. This dramatically
RE: [Syslog] RFC3195bis
David, -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 4:15 PM To: [EMAIL PROTECTED] Subject: [Syslog] RFC3195bis [.. big snip ..] Chris and I did not agree that RAW mode should be obsoleted and replaced with a new mode. That is new work that is NOT in the current charter, and is not in the proposal to Sam for a minor change to the charter. That is simply out of scope for the current WG. To my knowledge, there has been no discussion of such a change, and there is no current WG consensus to do this, even if it were in scope. As co-chair, I would not take such a proposal to Sam because we have work that is not yet completed, and that needs to be completed before we start working on new proposals. If there is WG consensus to obsolete both RAW and COOKED modes, then we can simply obsolete RFC3195 and move forward with sylog-sign. A new proposal for a TARTARE mode can be proposed as a new transport mapping in the future, under a different charter or as an individual draft. I agree that COOKED should be obsoleted. Reasons are in my other mail from earlier today. Even though I did not consider it before, obsoleting RAW also seems right to me. The reason is that this greatly simplifies interoperability between new (to be written) and existing applications. If we define a TARTARE mode, the BEEP greeting precisely tells sender and receiver what to expect. Keep in mind that RAW and TARTARE (or RAWbis) are incompatible to each other. This stems back to the fact that 3195 demands printable characters only as well as LF as a record delimiter. This does not work with a -protocol formatted message. The appropriate BEEP solution to that problem is to define a new profile. So creating TARTARE is the right thing to do. Everything else would be a bad compromise. I see your concerns in regard to the charter. I also understand John's concern. I like you proposal to simply obsolete 3195, then complete -sign and then work on a new version of 3195. There is no need to hurry in getting that done. Very few implementations are using it today and they continue to work (at least if somebody finally deploys them ;)). There is also no need to have a BEEP transport mapping ready in order to get -sign published. The whole point of the discussion was that -sign should be transport-independent. If it is independent, anything we specify now can also work with a later TARTARE BEEP transport. So there is no actual relationship. One might now argue that so -sign messages can not be used with 3195. This is right. But this is right in any case. Existing 3195 transports will never work with -sign. My conclusion: simply obsolete 3195, remove references to it from -sign and let's finish -sign quickly. Then recharter. Rainer [.. big snip ..] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] MIB Issue #2: document terminology.
David, I will happily do that. But before I can, I need to go back to the discussion on architecture in syslog-protocol. Is this issue solved? Do we need a new section or are the proposed definition updates enough? I am asking these questions because I think we need to be clear on the terminology before we check its usage in another document. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, January 15, 2007 6:58 PM To: [EMAIL PROTECTED] Subject: [Syslog] MIB Issue #2: document terminology. Hi, [speaking as co-chair] For issue#2, you do not need to worry about the MIB module itself, so a lack of SNMP expertise is not important to resolving this issue. I have a copy of an unofficial -02- revision of the syslog-device-mib that was edited by Bruno Pape, dated August 2002. The current mib draft inherited its terminology and architecture diagrams and support for multiple entities from the WG drafts edited by Bruno. So the current terminology and architecture and table structure was decided by the WG, in the adoption and subsequent development of the mib document. As WG editor, it is Glenn's responsibility to represent in the document the consensus of the WG; if only one WG member argues for substantial changes to an existing WG document, then there is no clear WG consensus to make such changes. We need multiple WG members to review the current MIB document for the chairs to determine that the terminology used in the text sections represents what the WG wants to see, and that WG agrees the text section adequately describes what information is needed to manage a syslog sender, receiver, relay, and/or collector. Again, you do not need to be SNMP-literate to do such a review; We need a review of the surrounding text. Please make suggestions for replacement text when you think the current text is not appropriate. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Syslog WG co-chair ___ 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] MIB Issue #1 - one or multiple? Seeking consensus
Being not MIB-literate, I tend to agree that it does not add much complexity if there is a table which most often includes just a single element. What is used in practice. It depends on your point of view. If you look at deployments, a single engine is the vast majority. If you look at number of different implementations, I am not so sure. In any case, I would vote for extensibility IF that does NOT add considerable complexity. I can not make an informed judgement on the later. Rainer -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 16, 2007 12:21 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Tom, Which technique is best depends on whether the occurrence of multiple instances is the norm, which should be modelled and supported. I think that this is not the case for syslog and so the additional complexity is not justified. I imagine you think otherwise. The syslogMIB leaves it to the users to choose how they want to manage their syslog entities. I do not see the problem with that. About complexity- there is hardly any added complexity worth mention in the MIB design, implementation, and corresponding NMS development. Glenn tom.petch wrote: - Original Message - From: Glenn M. Keeni [EMAIL PROTECTED] To: tom.petch [EMAIL PROTECTED] Cc: David Harrington [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 14, 2007 5:12 PM Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus tom.petch wrote: I do not believe that the MIB should be modelled to support multiple instances of a syslog device as an SNMP table. Where multiple instances do exist in a single machine, and there is a requirement to manage more than one with SNMP, then I believe that the usual SNMP techniques are adequate to support this and each can be modelled within the MIB module with scalar objects, thereby simplifying the MIB module and making more likely to be implemented. Using Tables is the standard SNMP technique for managing multiple instances. That is exactly what is done in the current MIB. Glenn Well, no. If you have two routers within a single box, served by a single agent, there is no table in any MIB module that has ever existed that allows you to have both router FIBs etc as part of a single object tree starting at 1.3.6.1.2.1. Some specific MIB modules have taken the view that multiple instances should be so supported and so have made tables of (almost) every object pertaining to the instance, as you have chosen to do with syslog. Most creators of MIB modules have not done this and have relied on other standard SNMP techniques to allow for the support of multiple instances of the router, hub, bridge, host etc etc etc by SNMP. Which technique is best depends on whether the occurrence of multiple instances is the norm, which should be modelled and supported. I think that this is not the case for syslog and so the additional complexity is not justified. I imagine you think otherwise. Tom Petch Glenn - Original Message - From: David Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 12, 2007 7:31 PM Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Hi, [speaking as co-chair] Finally, we are getting discussion of the issues of what needs to be modeled by more than two people with opposing ideas. I would like to reach consensus on this question: Is it acceptable practice to have more than one syslog application (sender, receiver, relay) running on a server/host/system simultaneously? At this point, based on Glenn's suggestion of having an experimental and a production syslogd running at the same time, and Rainer's description of syslog in a Windows environment, I think that having more than one active syslog application (sender/receiver/rerlay) is a reasonably common scenario in some environments and not in others. The current MIB interface is designed to support multiple syslog sender or receivers on the same server/host. I believe this is a valid requirement. If you agree with this, please say so. If you disagree with this, please say so. The chairs will make a determination of consensus, and this issue will be closed. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 3:30 AM To: [EMAIL PROTECTED] Subject: [Syslog] The SIMPLE SyslogMIB Hi, I will try to address David's concern about the complexity and utility of the MIB. The basic design principle has been to keep the MIB simple. It has gone through several iterations, each one making it simpler than
RE: [Syslog] Doubts on definitions
Hi Juergen,
The only thing that is special with syslog is that under one
operating
system (*nix), there is a different architecture with syslogd. It's
not
Windows that is different. It is the *nix implementation (at least
in
my
point of view). The problem is that *nix is obviously the dominant
implementation and that many boxes use linux as firmware. So this
is
probably the root cause of the problem.
I like to note that syslog was invented on Unix systems and hence I do
consider the Unix way of doing syslog to be somehow authoritative. But
we do not have to agree on this. ;-)
I agree that it is a strong point, thus I mentioned it. I am just saying
we can not REQUIRE everyone to do the same on other platforms. And again
we are talking on things not happening on the wire. But I think that's
just a minor issue ;)
I can offer to create a paper on the architecture of syslog in
different
environments. I am still doubtful if such a description belongs into
a
RFC. Maybe it is useful as an informational RFC. But again I think
we
can not *standardize* a software architecture. That does not make
sense.
Different environments and different use cases require different
architectures.
Dave Harrington's point is that you can't write a proper management
interface (a MIB module) without first understanding the architecture
of the thing you model in the management interface. And this is why
syslog people have to help the SNMP people to get their MIB modules
right. You are not asked to become an expert in SNMP/MIBs - all that
is needed is that you can help draw up a model for a management
interface that matches to ideally all existing syslog implementations.
For that, such a paper would be indeed useful.
I understand this and this is why I offered to write such a paper. But
the question remains if such a description belongs into a normative RFC.
Remember that the current discussion was spawned when David requested
that the architecture section in syslog-protocol is unclear and needs to
be extended. So far, my humble view is that *program architecture* does
NOT belong into a RFC. But this may be my inexperience and I am open to
good arguments why it should be...
Rainer
/js
--
Juergen Schoenwaelder {International|Jacobs} University
Bremen
http://www.eecs.iu-bremen.de/P.O. Box 750 561, 28725 Bremen,
Germany
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
I agree for the reasons outlined in mails before. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 7:31 PM To: [EMAIL PROTECTED] Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus Hi, [speaking as co-chair] Finally, we are getting discussion of the issues of what needs to be modeled by more than two people with opposing ideas. I would like to reach consensus on this question: Is it acceptable practice to have more than one syslog application (sender, receiver, relay) running on a server/host/system simultaneously? At this point, based on Glenn's suggestion of having an experimental and a production syslogd running at the same time, and Rainer's description of syslog in a Windows environment, I think that having more than one active syslog application (sender/receiver/rerlay) is a reasonably common scenario in some environments and not in others. The current MIB interface is designed to support multiple syslog sender or receivers on the same server/host. I believe this is a valid requirement. If you agree with this, please say so. If you disagree with this, please say so. The chairs will make a determination of consensus, and this issue will be closed. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Friday, January 12, 2007 3:30 AM To: [EMAIL PROTECTED] Subject: [Syslog] The SIMPLE SyslogMIB Hi, I will try to address David's concern about the complexity and utility of the MIB. The basic design principle has been to keep the MIB simple. It has gone through several iterations, each one making it simpler than the earlier version :-) At present the MIB basically allows the NMS to manage the syslog entity (sender, receiver, relay) by looking at its (a) status ( up/down/suspended/unknown) (b) configuration (c) macro statistics total number of messages (sent, received, relayed) total number of exceptions ( drops, discards, malforms) The notifications will tell the NMS about change in the syslog entity's status. That in a nutshell is what one will want to or need to do for basic monitoring/management. The MIB can provide information on multiple syslog entities. [Scenario: two syslogd's are running on a syslog server - one for experiments one for regular operations.] So if we want we may get a table like the following from the MIB. Syslog Status and Statistics Summary +-+-+--+--+-+-+-+ |Index|Type | Description |Status| Messages| | |rsR* | | |Sent | Recd| Dropped | +-+-+--+--+-+-+-+ | 1 |r-- | SecuritySys | Up | - | 120| - | | 2 |r-- | Operations | Up | - | 1234| - | | 3 |r-- | Experiment-1 | Up | - | 9890| - | | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | +-+-+--+--+-+-+-+ * r: Receiver , s: Sender, R: relay Note that this is a sample. Several other columns are possible. In a similar manner the address and port of the syslog receiver, the number of malformed messages received etc. can be obtained. In more advanced usage, a syslog entity can be started [on a specific address and port, if it is receiver] or an existing syslog entity can be stopped or suspended. [I will not try to explain how that can be done.] I think that is simple as it can be. Let me know if a. it can be made simpler. b. it is too simple and more detailed information is necessary. e.g. facility wise statistics as follows. Facility-wise Syslog Statistics Summary === +-++-+--+--+-+-+-+ |Index|Facility|Type | Description |Status| Messages| | ||rsR* | | |Sent | Recd| malformd| +-++-+--+--+-+-+-+ | 1 |51 |r-- | SecuritySys | Up | - | 123| - | | 1 |52 |r-- | SecuritySys | Up | - | 45|45 | | 1 |53 |r-- | SecuritySys | Up | - |6| - | | 2 |51 |r-- | Operations | Up | - | 789| - | | 2 |52 |r-- | Operations | Up | - | 10|10 | +-++-+--+--+-+-+-+ * r: Receiver , s: Sender, R: relay I will not recommend tables for - facility-wise and severity-wise statistics - facility-wise,
RE: [Syslog] Syslog Protocol doubts
Hi Glen, thanks for the message. Let me start on an overview level: if you look at the evolution of the draft, you will see that earlier versions were quite specific on what to do if the message was malformed. However, based on dicussion, one after another of these rules were deleted. The reason was always that MUSTs here are not actually needed to ensure interoperability. You can get a glimpse of this discussion by looking at http://www.syslog.cc/ietf/why-indepth.html This is a very old page. For more recent samples, you should consult the mailing list archives. There are (too) plenty samples of this being discussed to point to anything specific. The bottom line behind the current draft is that we do not necessarily specify what happens if the message is malformed. This is not vital for interoperability. Also, implementors will provide different solutions (most probably operator-configurable) to address real-world needs. For example, we could specify that a message with leap seconds in it MUST be discarded - but if the operator insists that he needs such a message, an implementor will always create a way to process it. We are specific on invalid UTF-8 sequences. This must not be interpreted, because this is a big security issue. However, even than it might be OK for an implementation to store the invalid UTF-8 sequence. If that is consensus, we can add the statement the handling of non-compliant messages will be implementation dependent which very precisely describes the list consensus. Rainer -Original Message- From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] Sent: Friday, January 05, 2007 12:32 PM To: [EMAIL PROTECTED] Subject: [Syslog] Syslog Protocol doubts Hi, I have been trying to figure out the error conditions that a syslog receiver will need to anticipate and the corresponding actions that it is expected to take. I do not see this clearly spelt out in the protocol document. There are several MUST clauses, I understand that a compliant syslog sender WILL always send messages that meet the MUST clauses. But the document does not spell out clearly what a compliant syslog receiver will do when it gets a non-compliant message. Possible actions could be: a. discard whole message b. discard non-compliant part ( assuming the non- compliant part can be isolated) c. rectify the non-compliance e.g. - truncate message: [this is mentioned in 6.1] - truncate the long-fields (software, swVersion etc.) d. implementation dependent Is this a problem ? I have listed the MUST conditions in the attached document. My take is that we may have to address each one of these. Or we can include a sweeping statement like non-compliant messages will be discarded or the handling of non-compliant messages will be implementation dependent. Glenn ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Syslog Protocol doubts
Hi Tom, I think this is an extreme position. The reason is that if I take this to its ultimate end, we would probably end up without any MUST in the draft. For example, should we just say the date SHOULD be given in RFC 3339 format ... But leave it open to any implementor what he intends to do? I think a MUST is justified here. But on the other hand, I can NOT force (MUST) an implementation to discard an otherwise useful message just because the date is in the wrong format. From the protocol perspective, this might be the right thing to do (in trying to punish the incompliant implementation), but from a usabulity point of view, the administrator needs to have this capability. In a closed-source environment, that means marketing will force an implementor to support it. In open-source, the administrator will simply modify the implementation himself. In either way, the MUST discard will not survive. So is it really smart to mandate something in a standard that we can foresee to be ignored (and that for good reason)? However, we need to set same baseline and these are the format-MUSTs. If we change them all to SHOULD (to cover a myriad of real-world cases), we do not have a standard... Rainer -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Friday, January 05, 2007 6:47 PM To: Rainer Gerhards; Glenn M. Keeni; [EMAIL PROTECTED] Subject: Re: [Syslog] Syslog Protocol doubts inline Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: Glenn M. Keeni [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 05, 2007 2:46 PM Subject: RE: [Syslog] Syslog Protocol doubts Hi Glen, thanks for the message. Let me start on an overview level: if you look at the evolution of the draft, you will see that earlier versions were quite specific on what to do if the message was malformed. However, based on dicussion, one after another of these rules were deleted. The reason was always that MUSTs here are not actually needed to ensure interoperability. tp I take a somewhat different view. To quote RFC2119, Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions). So if you receive a packet that breaks a MUST, you MUST discard it. If it breaks a SHOULD, then you MAY accept it, in fact I would say you ought to on the principle of being liberal in what you accept. tom Petch snip You can get a glimpse of this discussion by looking at http://www.syslog.cc/ietf/why-indepth.html ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] RFC 3195bis?
Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RFC 3195bis?
The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples -sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ 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] RFC 3195bis?
Ah... interesting. I knew that Cisco had something brewing, but I never heared that it was released. I still agree with you that 3195 should not specifically be mentioned by -sign. I assume that implementing 3195bis (when available) is probably not hard if you implemented 3195. Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 5:23 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] RFC 3195bis? Hi, I'm OK removing references to RFC 3195 from syslog-sign for the points you mention. I'd welcome other opinions. I agree that RFC 3195 is due for an update but I disagree with most of your other points. A major vendor has found customers requesting it and has implemented it. http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a 00807883c3.html Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: The Chairs have been discussing this already. We have a candidate to write the update. The length limit in RFC 3195 was constrained by RFC 3164 and we have moved beyond that with the transport IDs which identify realistic maximum lengths. Updating RFC 3195 to have a greater length should not be a problem. HOWEVER... We need to focus on syslog-sign and syslog-device-mib BEFORE doing this. Once we get the shepherding documents for those IDs sent to the IESG _THEN_ we can discuss 3195bis. The problem is that -sign is related (even depending) on 3195. This is why I brought up that issue. Let me explain. syslog-sign recommends 2k for signature and payload blocks. It does so, because it assumes (rightly for the new series) that 2k can be handled by almost every receiver, so there is no problem in using that length. However, if we require that -sign works together with 3195, we must lower this limit to 1k. I would not like to see this happen because 2k makes much sense and is much more efficient. 3195 does not seem as important: - it is due for update - there has only been an extremely limited set of implementations - none of the major vendors has implemented it - there is no (not virtually no!) customer demand for it at the time being (I know this because I have implemented RFC 3195) - the only customer demand comes from IHE, but for IHE it is not usable because it still contains a too-rigid length constraint In short: the current RFC 3195 is not really in use. An updated version may. I think we should not sacrifice the 2k limit for something that is not being used. So my propsal is: we should remove RFC 3195 from syslog-sign as well. It should simply reference -syslog-protocol and its transport mappings. RFC 3195bis will most likely be a transport mapping. Thus, -sign can cover it without specifically mentioning it. This works exactly as the new series is designed. Transports are below -protocol and sign is in the layer above it. So there should be no dependencies between -sign and the actual transports used. If we take that route, we only lose the ability to use -sign *reliably* with RFC 3195 as it is today. Given the fact that nobody is actually using 3195, this is not a huge loss ;). It also finally de-couples - sign from any other transport RFCs - and this was a major intention about the whole effort of the new syslog series. I suggest we all have a look at this slide from 2004: http://www.syslog.cc/ietf/presentat/syslog-protocol-03/img5.html Rainer Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: Hi all, now that we obsolete RFC 3164 by -syslog-protocol, the only remaining RFC that is not compatible to the new syslog series is RFC 3195. The questions is now how to proceed here? I am raising this issue because it has some effect on syslog-sign. I would love to see 2k as limit for sign-generated messages, but that means we need to talk about 3195 (which not explicitely supports messages over 1k). IMHO, we should do a 3195bis that updates 3195 to work as a transport mapping with syslog-protocol. After we've done that, we have finally unified all syslog RFCs and do not have any more issues with incompatibilities between them. I think this is something we should do soon. Comments? Rainer PS: I, too, would like to express my seasons greetings to all folks on the list! May you have a great and peaceful xmas time and a good start into the new year. ___ 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] WGLC -sign-20 rgerhards review
Hi all, finally, I have managed to do a thourough review. I have not excessively commented on issues that are already being discussed on list. All in all, the document is fine work and in good shape. My issues are mostly small nits and many of them connected to support for 3164 and 3195 (oh yes, we've almost forgotten about it...). I have one more substential comment (actually a suggestion) at the end of the review. While I reviewed the document I also thought how I would actually implement syslog-sign in the two (quite different) syslog products that I influence. I would like to express that section 7 is very helpful in understanding the overall concept and its implications. This is an excellent description. From the implementor's point of view, I think the document clearly conveys what needs to be done to implement the protocol. After reviewing, I have a clear understanding of where and what I need to modify in our software's design to implement -sign. Of course, there are probably some caveats that I will only detect if we actually implement it, but that should be no major issues. Now on to the details. abstract defined in RFC 3164, 3164 is informational, so it is described at most [same comment for section 1. and section 3. (first paragraph)] section 3. ## receiving renders the mechanism useless. For this reason, syslog sender and receiver implementations implementing this specification MUST support messages of up to and including 2048 octets in length, ## I didn't catch it when it was brought up on list before. I was thinking too much of syslog-protocol. However, we must stick with a max size of 1024 because neither RFC 3164 NOR RFC 3195 allow for more. In regard to 3195 this is somewhat debatable, but arguments that more is supported are on slippery ground. section 4.1 ## There is a need to distinguish the Signature Block itself from the syslog message that is used to carry a Signature Block Signature Blocks MUST be encompassed within completely formed syslog messages. ## I think there is a period missing Signature Block###.### Signature Blocks MUST -- No additional comment on APP-NAME, MSG-ID - see already existing thread ## Similarly, when used with traditional syslog [10], the Signature Block message MUST contain a valid TAG field. The TAG field MUST have the value of syslog (without the double quotes) to signify that this message was generated by the syslog process. ## I think ... was generated by the syslog process. implies a specific software architecture (which is beyond the scope of the IETF). I would recommend something along the lines of that this message is an administrative message inside the syslog protocol. --- section 4.2. --- The term bytes is used. I was advised some time ago that octets is more appropriate inside the IETF. The sample is missing the quotes around SD-PARAMs. It should read as follows: [ssign VER=xxx RSID=xxx SG=xxx SPRI=xxx GBC=xxx FMN=xxx CNT=xxx HB=xxx SIGN=xxx] section 4.2.1 The Signature Block version field is 4 characters in length. We must be careful. Syslog-protocol now mandates UTF-8 in this field. So a character is not equal to an octet. I guess octet is meant. If I read on, the term byte reappears. I suggest using a unified term. This comment also applies to the sections following after 4.2.1. --- section 4.2.3 --- This is not something overly important... but might it be possible to allow 999 sig groups when SG is '3'? I agree it is unlikely to have more than 192 groups, but does it hurt to support it in (rare) cases where it might be needed? section 4.2.4 I do not understand why the global block counter works across different signature groups. Wouldn't it be more useful if it were on a per-signature-group basis? I would appreciate if you could elaborate a little on the reasoning. section 4.2.5 What happens if the (first) message number latches at 99? What is the message number? I did not find it defined anywhere. Of course, I think I can guess (number of messages sent over this signature group since reboot?) what it means, but it should be defined. section 4.2.7 size needs to be changed back to 1024 (see above for reasons) section 5.2 -- Bullet Point b: I recommend to refer the timestamp from syslog-protocol (instead of RFC 3339) because code to handle that is already present in syslog applications. section 5.3. size needs to be changed back to 1024 (see above for reasons) section 5.3.2.1. Quotes need to be added to sample: [ssign-cert VER=xxx RSID=xxx SG=xxx SPRI=xxx TBPL=xxx INDEX=xxx FLEN=xxx FRAG=xxx SIGN=xxx] --- section 5.3.2.6. --- - This comment is just in case that we will (for whatever reason) stick with messages sizes above 1024: then, the fragment length must be 4 octets. This comment does not apply if we change back to 1024. - registry names must be suggested
RE: [Syslog] RFC 3164
Andrew, Anton, I am using Andrew's message to reply to both. I concur with Andrew, please see below... -Original Message- From: Andrew Ross [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:53 PM To: Rainer Gerhards Subject: RE: [Syslog] RFC 3164 Hi Rainer, Merry Christmas! Sorry I've been out of the discussion loop for so long, things have been pretty hectic over here. I know that the new protocols are in good hands though. With regard to 3164. I would prefer to obsolete 3164 with a document that details what is actually seen in real life on the wire. This would just mean adding some extra text to the 3164 document and adding in some examples of what is seen by different OS senders. Pretty much the research you presented to the list a while ago. This new document would then obsolete 3164. That would actually be my prefferred way to handle things. Other than Andrew, I think we should remove/change most of the text, as indeed only PRI is available on an universal basis. Samples of different message formats can be used to convey that information. We get asked so often by customers if we are 3164 compliant. We used to explain that 3164 is not really valid, but that didn't satisfy them, so we just said yes, we are compliant to keep them happy. Now to the question why do that?. Andrew has a very valid point here. We experience the same quite often. We even added an option use RFC 3164 compatible format to our product and guess what - it is turned off most of the time because RFC 3164 does not describe what receivers and senders typically do ;). Even if we obsolete 3164 with -protocol, I know a lot of folks will come and ask Hey, do you support the old standard that most of my other devices use?. They simply will not care about it being obsoleted by something different. However, if we go ahead and crate 3164bis (another informational document), the situation will IMHO change. Now there is a newer standard (as people perceive it) for the old syslog. And if that says You can not trust anything but PRI I can sell that. Plus, I have a very good point in argumenting why syslog-protocol is superior. I know I am not talking hard technical facts here. I am talking real life. Most people do not care if a RFC is informational or standards track. If it is a RFC, it must be something products comply too. I agree that implementors should understand the difference. They (hopefully/probably) do. But do implementors actually decide what to implement? No - not in my experience. The marketing department tells them what to do. And customers tell the marketing department. And guess what? These customers are the informed masses that do *not* know the inner workings of the IETF (aka a RFC is a RFC is a RFC...). Even in a technical context like the IETF I think a little bit of real-world politics can be considered. It is the key to acceptance of new standards. Rainer Cheers Andrew -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, 21 December 2006 8:13 p.m. To: [EMAIL PROTECTED] Subject: [Syslog] RFC 3164 Hi all, I just realized that the future of RFC 3164 is not yet publically discussed. RFC 3164 is a well-done work, but we have made much progress in the past 5 years since it was written. Most importantly, we discovered that actual syslog software uses a much different set of formats than expected by 3164. This was the source of much discussion inside the WG and we did a lot of testing to confirm the findings. The bottom line is that we now know that 3164 does *not* acurately describe what is observed in the wild. Nobody is to blame here - the breadth of information we created the past years was simply not available (nor were the ressources to do the testing) to the orginal authors of RFC 3164. Having said that, I think we must do something about the situation. In practice I see more and more vendors claim compliance to RFC 3164. This is kind of funny in itself, because 3164 is just an information document, so you can not be compliant to it ;) Anyhow, many vendors seem to have a wrong impression and use this in their advertising as well as tech support. I think we should do either one of the following: 1. create an updated RFC 3164bis 2. obsolete RFC 3164 I personally would tend to 1. - update the document with what we have gained on additional knowledge. I have been told that this would be somewhat unusual for the IETF, as 3164 is only informational and -transport-protocol will soon set a real standard. So updating information on the past seems not to be useful. However, I expect traditional syslog to stay around for at least another 5 to 10 years, if not longer. I would consider it a plus to have a RFC that accurately describes the format that we can expect from such a legacy syslog sender. Most importantly, it will remove any false secure feeling about format
RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, Ahh.. I see your point now. (Sorry - being a little slow this week.) All: I'm tending to agree with Rainer's point that no value should be specified for APP-NAME. Does anyone think that the document should suggest something for fixed-function devices such as printers which might not have a syslogd? Currently syslog-protocol allows a NILVALUE if nothing better can be used. I think they should use whatever the use with other messages. For example, they might use router. Sure, this is not intelligent. But my point is that this should not be of concern for syslog-sign. Similarly, PROCID may be NIVALUE in syslog-protocol if the device cannot produce it. I'm OK with that for syslog-sign as well. Finally, I'd still like to keep sig for the MSGID. This should allow for parsers (automated and manual searches) to find syslog-sign messages quickly. I do not object it, as long as we caution implementors that a MSGID of sig does not necessarily indicate this is a syslog-sign message. We can not guarantee that, because we did not reserve any message ids at all. So it may be a clue, but it is nothing to rely on. Which brings me to the point: what is the advantage of an unreliable indicator? This won't be the only mechanism to identify a syslog-sign message. I believe that a syslog-sign message would have to: - be sent to PRI = 110 - have MSGID = sig - contain an SD-ID with the SD-PARAM of ssign or ssign-cert I don't think that we need a registry of MSGIDs for this. For me, the SD-ID is the only valid indicator that this is a syslog-sign message. We can not rely on PRI as operators like to reconfigure PRI. Even if we mandate a fixed PRI in the specification, real-world implementations will ignore that requirement and still allow the operator to override it (and this for a good reason). On the other hand, SD-IDs *are* under IANA control and the absolutely positively identify the element that they are contained in. This is what we designed them for. So why not use them for their design purpose? With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer If anyone has issues with any of this, please speak up now. I'd like to get this settled so we can update and send this to the IESG when the WGLC ends. Thanks, Chis On Tue, 19 Dec 2006, Rainer Gerhards wrote: Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 10:18 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, On Mon, 18 Dec 2006, Rainer Gerhards wrote: Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so
RE: [Syslog] RFC 3164 in syslog-sign?
Chris, I would prefer __ No - take it out, we need to move the world along, as this removes a lot of complexity and guesswork. It will also be cleaner if rfc3164 is actually obsoleted by -syslog-protocol. If that is not WG consensus, I would recommend __ Maybe - move it to a non-normative appendix As a formal note, I am not sure if we can create normative text based on a non-normative document (rfc 3164). This sounds kind of wrong to me... Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 3:20 AM To: [EMAIL PROTECTED] Subject: [Syslog] RFC 3164 in syslog-sign? Hi, We started syslog-sign before we had Structured Data, and the original author was creating a mechanism that could be used within the RFC 3164 framework. However, times have changed. We now have syslog-protocol with SDs. Does the WG feel that syslog-sign should contain normative information on how to utilize the syslog-sign mechanism in the RFC 3164 format? Answers can be: __ Yes - leave it, it forms a bridge for transition, __ No - take it out, we need to move the world along, __ Maybe - move it to a non-normative appendix Thanks, Chris -- Forwarded message -- Date: Wed, 20 Dec 2006 15:51:25 +0100 From: Rainer Gerhards [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt ---some elided for brevity--- With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer ---remainder elided for brevity--- ___ 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] RFC 3164
Hi all, I just realized that the future of RFC 3164 is not yet publically discussed. RFC 3164 is a well-done work, but we have made much progress in the past 5 years since it was written. Most importantly, we discovered that actual syslog software uses a much different set of formats than expected by 3164. This was the source of much discussion inside the WG and we did a lot of testing to confirm the findings. The bottom line is that we now know that 3164 does *not* acurately describe what is observed in the wild. Nobody is to blame here - the breadth of information we created the past years was simply not available (nor were the ressources to do the testing) to the orginal authors of RFC 3164. Having said that, I think we must do something about the situation. In practice I see more and more vendors claim compliance to RFC 3164. This is kind of funny in itself, because 3164 is just an information document, so you can not be compliant to it ;) Anyhow, many vendors seem to have a wrong impression and use this in their advertising as well as tech support. I think we should do either one of the following: 1. create an updated RFC 3164bis 2. obsolete RFC 3164 I personally would tend to 1. - update the document with what we have gained on additional knowledge. I have been told that this would be somewhat unusual for the IETF, as 3164 is only informational and -transport-protocol will soon set a real standard. So updating information on the past seems not to be useful. However, I expect traditional syslog to stay around for at least another 5 to 10 years, if not longer. I would consider it a plus to have a RFC that accurately describes the format that we can expect from such a legacy syslog sender. Most importantly, it will remove any false secure feeling about format standardization where there is none. I would appreciate comments on this issue. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 10:18 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, On Mon, 18 Dec 2006, Rainer Gerhards wrote: Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. We're going to have ssign and ssign-cert as the SD-IDs used for syslog-sign. I don't think that there are any dependencies on APP-NAME, PROCID and MSGID for the proper working of syslog-sign; From the quoted text above: value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double If APP-NAME and MSG-ID *MUST* contain something specific, I think there is a strong dependency. they're just there to make sure that these messages are placed consistently into the right bins. The ssign and ssign-cert SD-IDs will be reserved for this. I do not see how this addresses the concerns I mentioned above. I can not implement it without interfering with my application design in a way that I do not find justified. How does mandating a specific APP-NAME and MSG-ID make sure that they are put into the right bins? Many stock syslogds can not even filter on these fields... Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Dbh re-Review of -mib-11, part 3
Just one comment... In general the default values will be used ( IPv4, UDP, port 512 etc.) by syslog entities. 514 is the IANA assigned port for UPD syslog. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. -- Version field: I recommend renaming it to something like Sig-Version to avoid mistaking -protocol VERSION and -sign Version. -- I hope I will be able to do a full review by the end of the week. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Dbh re-Review of -mib-11, part 1
So far, just one comment... 1.6 11) in SyslogSeverity, I recommend removing the second sentnece in the description The syslog protocol uses the values 0 (emergency) to 7 (debug). since this is already spelled out in the SYNTAX clause,andshows that 99 (other) is also used. Why do we need 99? Are other values valid? Partially fixed. When is other used? Response. other will be used to count messages that do not have severity in the range 0-7. The syslog protocol specs (-19.txt) does not disallow such messages. Actually, -syslog-protocol disallows this by the way the PRI value is specified (this was different in previous versions of the I-D). In short: PRI MOD 8 is severity. So if a severity greater than 7 would be given, it would actually modify the facility. See 6.2.1: -- The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. -- Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Syslog-mib-11
David, Sorry for the late reply. In my experience: it depends... Under Linux/Unix, it is most common to have a single instance of the syslog process running. All other processes communicate with that process via local IPC, but the ultimate sender is the single instance of syslogd running. I have seen some deployments where multiple syslogd's run on a single machine. This is rare and, if so, almost always because of different security domains (e.g. have a different process listen to locally generated messages vs. Network received messages). From a design perspective, it might be a choice to have multiple processes make up for the syslog subsystem. A real-world example is SDSC syslogd, which runs different stacks in different processes. Rsyslog also has the RFC 3195 receiver separated. AFAIK these processes do not share internal information. It is questionable if such can always be assumed. Under Windows, it is common to have different syslog sender processes, but typically only one receiver is running. This stems back to the fact that there is no syslog subsystem is available on Windows so every vendor brings in its own. The key difference to *nix is that here each program is itself a syslog sender, while under *nix each program formats the MSG part of the message, passes that to an API and the syslogd picks and sends it from there (effectively relaying the message). I hope this information is useful. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 9:36 PM To: [EMAIL PROTECTED] Subject: [Syslog] Syslog-mib-11 Hi, In my latest review of syslog-mib-11, I have started to believe that Tom was right when he questioned the MIB module design, which models multiple syslog entities in a table, so one SNMP engine deals with multiple syslog senders, relays, and/or recievers on the same host. This adds complexity in the MIB design that I am not convinced is necessary. As the terminology in the MIB document has gotten closer to other WG documents, this has become somewhat clearer to me. Tom recommended that the MIB module only model a single syslog entity. Different instantations of the MIB module can be represented as existing in different contexts (e.g. in different communities), so one SNMP engine can still deal with multiple syslog senders, relays, and/or receivers on the same host, but the MIB module itself becomes simpler. We should be sure the MIB module reflects real world requirements. I do not have much operational experience, so I need your input. In real deployments, is it **typical** to have multiple syslog stacks running on the same host, each with a different bind address and port number and config file? or is it more common for most applications to share one syslog process (e.g., daemon) that operates via one address/port? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] severity
David, I went through my notes. Retaining PRI as is is actually a charter item: --- Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the PRI at the start. Additional testing has shown that as long as the PRI is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the PRI at the start of the message and will introduce protocol versioning. --- So we can not change the PRI representation (and thus the representation of severity). From what I see in my notes, we simply copied over the 3164 text on PRI without any further thinking after we had set on this charter. I think this is the primary reason that it was not better spelled out and be undetected until now. Rainer Before we publish the spec as an RFC, is the WG satisfied with this restriction of severity to 0-7, and is the WG satisfied that this is clear and unambiguous in our spec? If the WG believes the 0-7 restriction is unacceotable, we will need to pull the draft back from the IESG and make changes to PRI. The last time a version was submitted (roughly a year ago), it was pulled back *because* PRI calculation was different from legacy syslog. This was the whole point in that discussion. And, yes, then there wasn't this restriction. IMHO we can not change that without going into a deep-inconsistency-loop of WG decisions. If the WG accepts the 0-7, but thinks the draft is not clear and unambiguous, then we could provide clarifying text as part of WGLC without pulling the draft back from the IESG. This is what I'd recommend. A simple sentence like severities MUST be in the range of 0 to 7 should do the job. Rainer David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, December 14, 2006 9:26 AM To: Glenn M. Keeni; [EMAIL PROTECTED] Subject: RE: [Syslog] Dbh re-Review of -mib-11, part 1 So far, just one comment... 1.6 11) in SyslogSeverity, I recommend removing the second sentnece in the description The syslog protocol uses the values 0 (emergency) to 7 (debug). since this is already spelled out in the SYNTAX clause,andshows that 99 (other) is also used. Why do we need 99? Are other values valid? Partially fixed. When is other used? Response. other will be used to count messages that do not have severity in the range 0-7. The syslog protocol specs (-19.txt) does not disallow such messages. Actually, -syslog-protocol disallows this by the way the PRI value is specified (this was different in previous versions of the I-D). In short: PRI MOD 8 is severity. So if a severity greater than 7 would be given, it would actually modify the facility. See 6.2.1: -- The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. -- Rainer ___ 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] Framing in syslog-transport-tls
Miao, WG, I have partially implemented syslog-transport-tls in two different programs (MonitorWare Agent and rsyslog). My focus was the framing, not tls itself (I needed the new framing for some other functionality, but that is a separate story). I would like to share my experience during that implementation. This is *not* necessarily a request for change. I just though that might also come up during IETF last call, so I think the information is useful. FRAME-LEN is a variable length field. It specifies the length of the frame including the length of FRAME-LEN itself. This is no real problem for the receiver. On the sender side, however, it is a bit tricky. I need to obtain the length of the ASCII-encoded field including the (potentially changing) size of itself. Let's look at a sample. We have a message with 996 octets. Now I obtain the information that I need 4 octets to encode this (996 ). I need to add that to the total message length, bringing me up to 1000 octets. Now, I need to re-check my buffer requirements. I now learn that I need a 5 octect encoding. This I need to add to the previous length of the message (996), resulting in a total frame length of 1001 octets. If we would just count the MSG part of the frame, there would be no such ambiguity, because I would set FRAME-LEN to whatever size I know the MSG part has. It would be 996 in this case. However, that would mean we have two different framing mechanisms inside the frame - octet stuffing (the SP) after the count and then octet counting for the rest of the message (I think http uses such a mechanism, but have not verified). On the other hand, I can easily implement the current specification with few lines of code. Here is a C sample of the code I actually use in rsyslog: iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), %d , len); iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), %d , len + iLenBuf); Where len is the length of SYSLOG-MSG and iLenBuf the total frame length. For context, see http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?revision=1. 159view=markup and scroll down to line 1766. Initially, I was of the view that it would be advisable to think about changing -transport-tls so that the octet count is just the length of SYSLOG-MSG. After some thinking, I now believe that it is fine as it currently is specified. I suggest a sentence warning to implementors to point to the potential mis-implementation. On the other hand, a receiver must rely on the octet-stuffing in any case. Because it needs to find the SP in order to find the end of the octet count. That would be an argument to contain only the size of SYSLOG-MSG in the counter. Given the fact that -transport-tls is already submitted to the IESG AND there is no real problem with the current specification, I propose not to change it (except for adding a warning as outlined above). Sorry for the late catch, but these things seem to only appear when you actually implement... I would appreciate comments on the issue. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
Just for the records: I am also statisfied with this wording. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 6:46 AM To: 'Miao Fuyou'; Rainer Gerhards; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document That wording satisfies me. dbh -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, November 27, 2006 9:07 PM To: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document I am changing the sentence to: For the deployment where confidentiality is a concern, receiver authentication is required for sender/relay to make sure it is talking to the right peer. It is up to the operator to decide whether confidentiality is a concern for a specific deployment. This sentence serves as a tip for deployer rather than something about on-the-wire protocol. Thanks, Miao -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 8:27 AM To: 'Rainer Gerhards'; 'Miao Fuyou'; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 2:48 AM To: Miao Fuyou; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document - 5.1 == When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. == I do not find the MUST is appropriate here: when confidentiality is a concern is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of when confidentiality is a concern. Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. Probably lower case. The point is confidentility is meaningless without authenticaion. Well... maybe it is just a wording issue. Are we actually REQUIREING a sender to authenticate the receiver in all cases? If so, we should state that. My impression so far is that this is something that is optional and at the discretion of the sender or the operator configuring it. If so, we should state that clearly too. As an implementor, I am unsure what to do if I use the above text as a guideline. Standards do not typically require an operator to use the technology in a specific manner; Standards do typically require implementers to implement in a way so that operators CAN configure the technology in the preferred (interoperable) manner. MUST is used when the on-the-wire format/information/etc. must be interoperable for the protocol to work properly. I do not like seeing must in a document; either it deserves to be a MUST, i.e. it impacts on-the-wire interoperability, or it is an implementation/usage decision and we should not mandate it. If you use a lower case must, then you'll need to convince me as co-chair that the usage is justifed before I send it to the IESG. Dbh ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Shepherding document for udp-08
-Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 2:08 AM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: RE: [Syslog] Shepherding document for udp-08 Hi, Yes, I/we should correct this. Do we have any information about vendors that have implemented the current UDP specification? As of my end: not yet. I'll try to have a look into rsyslog this week and see if there is anything that makes it an issue. Rainer dbh -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 6:29 AM To: David Harrington; [EMAIL PROTECTED] Subject: RE: [Syslog] Shepherding document for udp-08 David, there is one minor thing in the shepherding document I do not concur with: -- This document describes the traditional udp transport for syslog. draft-ietf-syslog-protocol makes changes to the syntax of the syslog fields but this is just the udp transport. It could be said that all existing implementations of syslog use this specification. -- There are some changes in -transport-udp compared to the traditional transport. I think it is somewhat dangerous to draw the conclusion drawn. But as I said - this is a minor comment and probably depend's on ones point of view... Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 12:41 AM To: [EMAIL PROTECTED] Subject: [Syslog] Shepherding document for udp-08 Hi, I have reviewed a pre-publication copy of -08- and am satisifed it represents WG consensus and is of a quality sufficient for advancement to Proposed Standard. Barring serious objection from the WG, revision -08- will be submitted to the IESG for advancement, accompanied by the attached shepherding document. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues
Tom, -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 12:18 PM To: Chris Lonvick; Miao Fuyou Cc: [EMAIL PROTECTED] Subject: TLS RFC was Re: [Syslog] Towards closure of syslog-tls issues The latest TLS RFC is RFC4346 which is amended by RFC4366, RFC4680 and RFC4681 as rfc-index states; the last does not include RFC4507, which I would. However, the TLS WG is working on draft-ietf-tls-rfc4346-bis which changes the PRF (away from MD5) inter alia and calls it TLS v1.2. IMO, that I-D is too far away from completion to be worth waiting for but, in the sentence that notes that implementors and deployers should keep aware of current literature I would include a reference to include ongoing work in the IETF on TLS. I am not sure here, but I think any reference to ongoing work will put the I-D to a hold. The reasoning is that any draft expires and after at most 6 month there is nothing left that could be referenced. If I am right with this opinion, I consider it better not to mention any specific effort. I also think that the text Miao proposed should be sufficiently enough to alert an implementor (and operator) to watch for further references. Just my 2 cts... Rainer Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: Miao Fuyou [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 27, 2006 11:05 PM Subject: Re: [Syslog] Towards closure of syslog-tls issues Hi Miao, On Mon, 27 Nov 2006, Miao Fuyou wrote: Hi, Unfortunately (or fortunately), there are several issues raised after the chair start shepherding process. As the editor, I would like close the issues as soon as possible, and get the doucment updated. 1, Version. The wg seems have concensus on removing version from the transport mapping this time. If there is a objection, please reply. If no, I would remove it. Please remove the version. We have consensus to do this. Tom Petch does raise an important point that I will bring up to our ADs. Essentially, TLS does not have any mechanism to allow for an indication of the contents that it is protecting. This results in the need for separate ports for implementations of foo/TLS and bar/TLS, even to the point of foo.v2/TLS needs a different port from foo.v1/TLS. Both IPsec and SSH (as examples of other secure transports) are able to embed an indication of the payload within the transport protocol and reuse their ports. To that end, even the byte-count is a bit of a problem, but we'll live with that. Remove Section 6.2 as well. 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I tend to accept the proposal. Please comment if you have a different idea! Go ahead and remove that reference. 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html In addition to that - reference the latest TLS RFC and note that there are updates to that which need to be considered - note that the latest ciphers and their relative strengths may be found in BCP86 - note that implementors and deployers should keep aware of current literature (This should be about 3 sentences.) 4, ABNF issues. I will change format back to %d format. OK 5, Receiver authentication when confidentiality is concern, from MUST to must, and probably some more sentences about receiver authentication is required. OK Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris Please feedback if you have different ideas to the proposals above! Thanks! Regards, Miao ___ 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] Updated Syslog-tls Document
Hi Miao, thanks for the update. I have gone through the draft again and found some, mostly minor, issue. I have listed them below: - 3.0 == The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. == Do we really intend to support RFC 3164-style syslog (read: nothing known about the message format) over this transport? If so, the consequence is that implementations of -transport-tls must check for 3164 format and eventually be able to handle it. I suggest removing these two sentence, as it looks we encourage that case. If they stay, we should clearly state that a receiver is NOT REQUIRED to implement this. - Section 4.3, inside the ABNF: SP = I think this is problematic in respect to 2.4 of RFC 4234. I suggest replacing by SP = %d32 - 5.1 == When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. == I do not find the MUST is appropriate here: when confidentiality is a concern is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of when confidentiality is a concern. Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. - 5.2 Isn't that a security consideration (and belongs to that secition)? - 6.2 IANA registry names must be suggested (of course this comment is irrelevant if we drop VERSION). - Consistent Spelling Both version and VERSION is used for the respectively-named field. I suggest to resort to a single spelling. This also removes some ambiguities if the version field or the concept of a version is meant in some parts of the text. I suggest using VERSION consistently for the respective field. - Security Considerations is missing I wonder I didn't spot this earlier. IMHO any document must have a Security Considerations section. Of course, the whole document talks about security, but does that obsolete the section showing the weaknesses of the protocol? For example, I have at least three candiates to be included: - Problems in relay scenario A relay may receive data via traditional syslog and forward it via a tls-encrypted channel to its next destination. In this case, the channel to the next hop is secured, but the trust level of the message is considerably lower. - there is no rule that a sender must use the same host name inside the -protocol HOSTNAME field as it uses in the certificate's common name. I think that has some security implications. - cipher suites and such are left to the operator. We should indicate the (serious) consequences of this selection - One note on the cipher suites: I know there has been some discussion previously, but I wasn't able to find the post in question in the archive. Probably you can help me out. Question: how do we guarantee a minimum interoperability of implementations of this document if we do not specify any cipher suite? - Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 2:13 AM To: [EMAIL PROTECTED] Subject: [Syslog] Updated Syslog-tls Document Hi, There are two major changes since last update. 1, Section 3 is removed. It is an introductory text on TLS, and is neccesary because TLS is already a normative reference. 2, Updated the section 4.3.2 (original 5.3.2), removed the text about TLS layer alert to signal a syslog-transport event Regards Miao ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
-Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 10:40 AM To: Rainer Gerhards; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document I questioned the need for a version number for the TLS transport in private conversation and now I bring this up again here. Was that private? I thought it was on-list. Anyhow... I The public messege can be found at: http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html It seems there was a rough concensus that the version number was welcomed to save port resource when we discussed this issue on the mailing list. That is the reason why a version number is there. Agreed, I am guilty of not saying I agree on the mailing list. But to me that did not look like consensus but simply an overlooked message (there were no responses at all...). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Revision 18 of Syslog-Protocol has been posted
Hello all, I have yesterday posted the latest revision of syslog-protocol to the draft editor. I expect it to come up on the I-D announcement list today. For those interested in a preview, I have made it available at http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-18.txt -protocol-18 contains changes requested during the last WGLC in August. Thankfully, there have been a number of excellent comments. I had prepared a change list for the chairs. Rather than now tearing that list apart and sending seperate replies to the mails (which will often miss the context), I have made this list available publically: http://www.syslog.cc/ietf/drafts/2nd-wglc-response-chris-public.html -- black text is orginal comment, green is me, red is chair or to be discussed (if RG: is present in front) -- Please note that discussion on ITU Preceived Severity has been re-initiated and I have not yet (re)moved that part from the document. Not included in this list are some editorial changes I did early in August. They are outlined here: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00785.html I would appreciate any comments on the new draft. I would also once again like to express my gratitude to everyone who commented on the previous version. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Shepherding document for udp-08
David, there is one minor thing in the shepherding document I do not concur with: -- This document describes the traditional udp transport for syslog. draft-ietf-syslog-protocol makes changes to the syntax of the syslog fields but this is just the udp transport. It could be said that all existing implementations of syslog use this specification. -- There are some changes in -transport-udp compared to the traditional transport. I think it is somewhat dangerous to draw the conclusion drawn. But as I said - this is a minor comment and probably depend's on ones point of view... Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 12:41 AM To: [EMAIL PROTECTED] Subject: [Syslog] Shepherding document for udp-08 Hi, I have reviewed a pre-publication copy of -08- and am satisifed it represents WG consensus and is of a quality sufficient for advancement to Proposed Standard. Barring serious objection from the WG, revision -08- will be submitted to the IESG for advancement, accompanied by the attached shepherding document. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
Tom, tp Ports may or may not be scarce but they are expensive. Introduce a new one and - anyone with firewall - anyone with an application level gateway - anyone with a packet filtering router has to go out and change each and every box to reflect the new assignment, a slow and costly process. This cost is often ignored by protocol designers. I agree with you on that. But I think the chance is extremely low that a considerate change is required. Even then, we could implement some version checking via special sequences at a later stage. But my root cause is that I do not expect a change. As to header change, the elephant in the room is the IPR hanging over this work which we can do no more about except wait to see what materialises; it could result in a change. I do not want to get on the slippery slope of the IPR discussion here again. But: if there will be a valid patent on something as trivial as using an octet count followed by a space followed by the data, then you will probably never find anything at all that is unaffected by the IPR. So I consider the IPR discussion to be actually irrelevant. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt
Chris, I mostly agree (but keep my posting on -04 in mind). Some issue below... Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 3:03 PM To: [EMAIL PROTECTED] Subject: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt Hi, Below is the first draft for the shepherding document for draft-ietf-syslog-transport-tls-04.txt. Please review and send feedback to the list. All of this is pending final reviews of the latest document submitted. === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-04.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-04.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick [EMAIL PROTECTED] === (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Chris Lonvick [EMAIL PROTECTED] Yes; I believe that the document is ready for publication. === (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has occurred from WG members, and it has been reviewed by others. The reviews of the WG Last Call for this document (-03 version) may be found here: Bert Wijnen's review (not a member of the WG mailing list) http://www1.ietf.org/mail-archive/web/syslog/current/msg01244.html John Calcote's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01199.html Other reviews of particular sections and concepts fill the WG mailing list. Of note is Eric Rescorla's review (of -02) http://www1.ietf.org/mail-archive/web/syslog/current/msg01100.html The issues raised in these reviews have been discussed on the mailing list and I am satisfied about the level of review. === (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns. === (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no concerns about the technical merit of the document. === (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus to publish this document. === (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeals have been threatened. === (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? XXX - Let's see what --04 looks like - XXX === (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informational references. The document is dependant upon
RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt
Chris, This protocol has very similar characteristics to implementations of syslog over ssl that are available at this time. Members of the Working Group have noted that it should be a very small change to bring those implementations in line with this specification. from my perspective, that text is excellent. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-protocol-18.txt
Chris, Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No one has come forth to claim that they have an existing implementation of this protocol at this time. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. The above named reviewers did an outstanding and thorough job. Though not a major application, I have implemented syslog-protocol-15 in rsyslog. Please see: http://www.rsyslog.com/index.php?module=Static_Docsfunc=viewf=/syslog- protocol.html at least, it is open source and other can have a look at it. I plan to update the implementation as soon as I have the impression the draft will move on without any futher changes or discussion. -transport-tls is not yet implemented but will probably happen within the same timeframe (also based on the impression that there won't be any major change). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
Miao, -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 2:24 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document The public messege can be found at: http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html It seems there was a rough concensus that the version number was welcomed to save port resource when we discussed this issue on the mailing list. That is the reason why a version number is there. Agreed, I am guilty of not saying I agree on the mailing list. But to me that did not look like consensus but simply an overlooked message (there were no responses at all...). Don't feel guilty because you did say I applaude:-) http://www1.ietf.org/mail-archive/web/syslog/current/msg01198.html I also found support from other active WG members. Yes, I know I did say that at that time. But the new Argument from Juergen was convincing to me. During the nearly 4 years of -protocol, we have often revised our view based on new arguments and I think this good. Anyway, let's reconsider the decision and make it right! Good point. It would be helpful if some other WG members could voice an opinion. We are on a thight deadline. There are only very few things for dicsussion in -transport-tls. If we act fast, I am confident Miao will be able to very quickly create a new revision (if necessary). Rainer Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
Hi Miao, inline Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 3:38 AM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document Hi, Rainer, Thanks for your thorough review! Some responses are inline. - 3.0 == The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. == Do we really intend to support RFC 3164-style syslog (read: nothing known about the message format) over this transport? If so, the consequence is that implementations of -transport-tls must check for 3164 format and eventually be able to handle it. I suggest removing these two sentence, as it looks we encourage that case. If they stay, we should clearly state that a receiver is NOT REQUIRED to implement this. Agreed. More comments from WG is welcome! - Section 4.3, inside the ABNF: SP = I think this is problematic in respect to 2.4 of RFC 4234. I suggest replacing by SP = %d32 I checked the ABNF with: http://rtg.ietf.org/~fenner/abnf.cgi It seems the tools suggest to use rather than %d32. I checked RFC4234, it says that it permits the specification of literal text strings directly, enclosed in quotation-marks. I will changed it back to %d32 to keep it consitent with the syslog protocol. Interesting. I am using http://www.apps.ietf.org/abnf.html. I will also try the one you used and do an additional verification on -protocol with it. However, I still find that %d32 is more precise than and I also have the impression that RFC 4234 recommends that form (but I may be wrong). Bottom line: I am more happy with %d32 (or %x20 as I think all others are in hex in the doc). - 5.1 == When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. == I do not find the MUST is appropriate here: when confidentiality is a concern is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of when confidentiality is a concern. Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. Probably lower case. The point is confidentility is meaningless without authenticaion. Well... maybe it is just a wording issue. Are we actually REQUIREING a sender to authenticate the receiver in all cases? If so, we should state that. My impression so far is that this is something that is optional and at the discretion of the sender or the operator configuring it. If so, we should state that clearly too. As an implementor, I am unsure what to do if I use the above text as a guideline. - 5.2 Isn't that a security consideration (and belongs to that secition)? RFC3552 request the residual risk should be descripted in the security consideration section. The section is about residual risk of generic certificate. see below... - 6.2 IANA registry names must be suggested (of course this comment is irrelevant if we drop VERSION). - Consistent Spelling Both version and VERSION is used for the respectively-named field. I suggest to resort to a single spelling. This also removes some ambiguities if the version field or the concept of a version is meant in some parts of the text. I suggest using VERSION consistently for the respective field. Agreed. - Security Considerations is missing I wonder I didn't spot this earlier. IMHO any document must have a Security Considerations section. Of course, the whole document talks about security, but does that obsolete the section showing the weaknesses of the protocol? Section 5 is Security Consideration, but maybe I should add a S to it (Security Considerations):-) (also on 5.2) - I must have been blind. I've gone several time through the document and always overlooked the title of section 5. I am not sure if the additional s had helped my ignorance ;) So I think you can disregard my comment. For example, I have at least three candiates to be included: - Problems in relay scenario A relay may receive data via traditional syslog and forward it via a tls-encrypted channel to its next destination. In this case, the channel to the next hop is secured
RE: [Syslog] WG timeline update - again
Hi David, I'd got no connectivity the past days. Further, I am now on vacation. I will try to work on -protocol, but I can not promise to do so before I am back to office (Sept, 18th). Honestly, my top priority currently is to keep my family happy. I hope you understand. For the very same reason, I will probably be unable to comment on the other documents. I hope you understand. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 5:53 PM To: [EMAIL PROTECTED] Subject: [Syslog] WG timeline update - again Hi, In the original timeline, we planned to start the WGLC for syslog-tls on Aug 28, but we didn't have an updated document to work with. Now a revision has been published, so we'll start the WGLC now. Here is another update to the timeline Aug 28 Close WGLC on protocol and udp Aug 28 start WGLC on syslog-sign Aug 29 tls drafts published with requested changes (before WGLC) Aug 29 start WGLC on syslog-tls Sep 1 mib draftspublished with requested changes (before WGLC) Sep 4 start WGLC on mib draft Sep 11 Close WGLC on syslog-sign Sep 11 revisions of protocol and udp drafts (after WGLC) Sep 12 Close WGLC on syslog-tls document Sep 18 Close WGLC for mib Sep 25 revisions of sign, tls, mib Sep 25 start final WGLC on all modified documents if needed. Oct 9 end final WGLCs Oct 20 submit all final-WGLC-modified drafts to internet-drafts Oct 23 publication cut-off preceding IETF67 Nov 1 submit documents to the IESG. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Legitimate \n or byte-counting
David, I have just now be able to poll my mail. I trust you as a co-chair that this time the documents will not be torn apart because of the missing backwards compatibility. Thus, I agree we should move to octet-couting, as there is more consensus to use that (and it is technically superior). I would just deeply appreciate if you could try to make sure this will not be the reason for violent objection of the document set as it was last year. Thanks for driving this discussion and getting us to consensus. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 4:20 PM To: 'Carson Gaspar'; [EMAIL PROTECTED] Subject: RE: [Syslog] Legitimate \n or byte-counting Hi, [speaking as co-chair] I believe it is inaccurate to say there has been a WG decision to maximize backwards compatibility. The charter says 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. There is a big difference between maximizing for backwards compatibility and considering the ease of migration between and the co-existence of existing versions and the standard. This difference was discussed during the charter discussions. We need to balance backwards compatibility with improved interoperability and good technical design. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: Carson Gaspar [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 4:19 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] Legitimate \n or byte-counting --On Friday, August 18, 2006 7:35 AM -0700 Chris Lonvick [EMAIL PROTECTED] wrote: If we use LF-escaping in syslog messages, what's going to happen if a legitimate \n is sent by a sender? An example would be: PRI... BOM The offending characters are \n Will a receiver convert that into LF? If that's the case then we should not be using LF-escaping. I raised the same issue. The answer is the receiver will examine the protocol version and will not un-escape unless the sender is a new-style sender. I'm still not convinced that the installed base of TCP syslog deployments is large enough to care about, but, given the decision to maximize backwards comparability, this is good enough to make implementation possible. -- Carson ___ 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] RE: byte-counting vs special character
inline -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 11:25 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: byte-counting vs special character Hi Rainer, [speaking as co-chair] Can we change the subject line to byte-counting vs special character for this topic so it is easier to find comments on this topic as compared to other things in the timeline? That will make it nuch easier for the chairs. Sure This WG has already gotten stuck, and had WG progress stall, trying to provide backwards compatibility to a bunch of incompatible implementations. I argued on this list before becoming co-chair that backwarsd compatibility may not be achieveable for some features and we need to stop getting hung up on it. Sometimes to build a good standard, you need to choose something that will break some existing implementations. I raised this concern with Chris when I started as co-chair. I do not want to see backwards compatibility arguments stall progress again. I made sure this was reflected in the timeline, which says that by Friday (if you decide to use a special character) you must reach consensus on which special character to use. [/speaking as co-chair] As you know, I have originally opted for octet-couting. However, I am trying to describe what made me think this is a sub-optimal solution. I think backwards compatibilty can easily be brought in here. However, I do not think this is a vital point. I can live with octet-couting and would not object it if it is the WG consensus to use it. So far, I've not seen a clear consesus for either. What I would find very unfortunate is using both escapes and octet-counting (for the reasons outlined in previous mails - gains nothing, costs many). To fulfil your requirement, I propse that we use the backslash character (\) as escape if we should decide to go the escape way. [speaking as contributor] I like the argument that the LF solution will not break existing implementations, but I would like to know this is actually true. Have you actually tested this against multiple implementations, or is it a theoretical argument? No, it's a practical one, but based on plain tcp transport seen in the wild. I know for sure that Cisco PIX, syslog-ng, rsyslog, WinSyslog/MonitorWare and most probably Kiwi syslog support LF as terminator (Kiwi with a leading CR as Andrew has pointed out). All of these solutions interop via ssl if used with stunnel. I know you have tested a number of other proposed ways of doing things against multiple implementations to try to verify backwards compatibility. Have you actually tested multiple existing implementations with the LF and found that they do continue to work without significant problems? Can you tell the WG which ones you have tested? Are there implementations that break when using this solution? All quoted above rely on the LF. If it is not present, at least most of them will merge syslog records (I can not at this moment verify the later for all one mentioned because I have no lab access). So far, my understanding was that stunnel is basically compatible to what -transport-tls specifies. Miao has questions that this morning. Again, I can not verify at this time (not even having a -transport-tls implementation at hand). I have asked Miao for details where he sees the incompatibility. When he replies, his argument might actually settle the whole issue and proove me wrong. In a different message you argue that syslog-sign only needs to support -protocol because the implementations will need to have new code added anyway, and the added complexity of backwards compatibility to rfc3164 implementations is not needed. I see a big difference here. To support -sign, all new implementations are needed. -tls (at least in my current view) does not come with this restriction. You only mention one implementation explicitly that provides syslog/tls, syslog-ng over stunnel. Would all the other implementations need to be modified to support a TLS substrate anyway, so it would not make a difference to them which special character was chosen or if byte-counting was chosen? Which syslog/tls implementations will be impacted by our choice here? Stunnel is a wrapper. It works with anything that runs on tcp. I have mentioned syslog-ng because it is the best known (and nothing I am involved with). All implementations I have quoted work with stunnel and are interoperable in that way (again, Kiwi only 98% sure). Ideally, only the implementations that support a feature need to pay the price for the feature. A syslog message delineator will only be needed in implemntations that add support for syslog/tls (or other streams). Whether one supports byte-counting or a special character, only implementations that support multiple messages in a stream, e.g. syslog/tls, should need to be modified to support the choice. Personally
RE: [Syslog] RE: byte-counting vs special character
Carson, Legacy code does not contain LF in messages. It is advised that new-style syslog also does not contain control characters (though it now is allowed). Thus the argument is valid. Again, I do not object octet-couting (I actually introduced the idea ;)) but find it the second best-solution. Maybe we should do a simple poll - some have already voiced their choices... Rainer -Original Message- From: Carson Gaspar [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 1:33 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] RE: byte-counting vs special character Escaping precludes no-configuration backwards compatibility, as no legacy syslog-over-tcp code does escaping. So if you want to interoperate with existing code, you must have a don't escape or expect escapes switch in your code. If you're going to do that, just have a LF mode vs byte-count mode switch. This whole backwards compat argument is bogus, iff we decide to escape embedded LF instead of forbidding it. And I have yet to see anyone argue for LF on any grounds except backwards compatibility. -- Carson ___ 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] timeline
Miao, I am actually concerned about backward compatibility with existing code *without* the need to upgrade any of that code. As you know, deployed software tends to stick. If we use just LF, existing, deployed technology (e.g. syslog-ng with stunnel) would be able to understand a message sent from a new style syslogd. Having the octet count in front of the message removes that ability, as the old syslogd will no longer see the pri at the start of the message. I agree that it is trivial to modify code to take care for the octet counter. But this is not my concern. My concern is that I would like to achive as good as possible compatibility with existing deployed (aka unmodified) technology. I should have been more specific on that. Sorry for the omission... I am also unaware of any implementation that mandates CR LF over just LF. Could you let me know which ones are these? Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 7:07 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] timeline Hi, Rainer, A new implementation could rely on byte-counting only and then delete LF from the frame(appplication knows exactly where the LF is), it may not force us to use escapes. For LF, I think it is difficult to get 100% compatibility for a legacy implementation to comply TLS-transport without any change to the code. At least, some imlementation may need to change CR LF to LF because some implementations use CR LF rather than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP from the frame. I still prefer byte-counting only to byte-counting+LF even if it is a feasible tradeoff. Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 10:18 PM To: Miao Fuyou Subject: RE: [Syslog] timeline We should not go byte-counting + LF. This is the worst choice: it A) breaks compatibility B) Forces us to use escapes So we get the bad of both worlds, without any benefits. Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 12:58 AM To: 'Anton Okmianski (aokmians)'; 'David Harrington'; [EMAIL PROTECTED] Subject: RE: [Syslog] timeline My vote: byte-counting only byte-counting + LF LF ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Syslog-sign -protocol
Chris, Sorry, I obviously had a previous copy cached... I've just downloaded a fresh one and started re-reading it. As you say, it already is adapted to syslog-protocol. Let me raise one point without being completely through with it: -sign now supports RFC 3164, 3195 and -protocol format. I see value in that approach (works for each and everything). On the other hand, it may introduce additional complexity, even on the operator side (configuration). Given the fact that -sign code needs to be written from scratch, wouldn't it make sense to limit it to just -protocol format? Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 8:33 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Syslog-sign -protocol Hi All, On Sun, 13 Aug 2006, Rainer Gerhards wrote: Hi, A general comment: syslog-sign is still based on rfc 3164 and has ist own format definitions. It needs to be edited to utilize the new work in syslog-protocol. It should now use structured data for ist signature blocks. Alex has moved much of it to be conformant with syslog-protocol. The work that needs to be addressed (as I see it :) For the Signature Block, should the payload of signatures be part of the ssign SD-ID, or should it be the payload (behind the BOM)? Right now, it is part of the SD-ID. Similarly, about the ssign-cert and it's payload. I think it likely that the Payload Block can be placed within a single Certificate Block based upon our discussions of the max length. The document needs to define how to use @enterpriseID in some cases. Section 8.2 - the length is no longer limited to 1024B. Section 9 - Cookie Fields are no longer used. The IANA section also needs to specify which SD-IDs and SD-Params should be registered. Should other SD-IDs be included with ssign and ssign-cert SD-IDs? (I think so as that's how we include information about time accuracy, etc.) Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Syslog-sign -protocol
Hi, A general comment: syslog-sign is still based on rfc 3164 and has ist own format definitions. It needs to be edited to utilize the new work in syslog-protocol. It should now use structured data for ist signature blocks. rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] delineated datagrams
No,we have not called for interopo with 3164. As there are very few 3164 compliant (not a standard) implementation, we can not find any common ground. Even more essential, 3164 is purely UDP, so there is no such thing as a 3164 compliant tcp sender. I agree, however, that -transport-tls can easily be used together with existing syslog/tls implementations if we use LF (and no octet count). It then comes down to what is described in syslog-protocol for interop with existing implementations. This is why I would prefer that mode. Rainer -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 2:10 PM To: Nagaraj Varadharajan (nagarajv); [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagrams I thought we were targeting the TLS transport to the new syslog-protocol, not the current informational RFC 3164. There are some considerations in the charter for partial syslog-protocol compatibility with RFC 3164. But I don't think we have called for the new transport to necessarily work with RFC 3164, did we? Does this need to be a requirement or can the implementations that wish to support both provide features to transition clients from one to another? Thanks, Anton. -Original Message- From: Nagaraj Varadharajan (nagarajv) Sent: Friday, August 11, 2006 3:51 PM To: [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagrams Sorry for jumping in late on this topic and also pardon me if I have not understood the discussion correctly. My thought is that the easiest way syslog over tls will be implemented will be by existing apps taking what they have for syslog over TCP and adding the TLS layer. So in terms of easy implementation and adoption, it may be good to support whatever is being done for tcp syslogs now. I believe that LF as a separator is quite common currently. However, I do agree that this is a good opportunity to upgrade to a better method. My only concern is that this should not force applications to drastically change their underlying syslog implementations Regards, Nagaraj -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 9:22 PM To: Balazs Scheidler Cc: [EMAIL PROTECTED]; Tom Petch Subject: RE: [Syslog] delineated datagrams Maybe this already has been said ;) This makes sense. What about other control characters? We need to differentiate between on-the-wire format and storage format. On-the-wire, I would escape only LF and the escape character. In storage, I would escape any control character (which can be quite tricky with Unicode). Our current scope (and IETF scope) is on-the-wire. So I propose not to mangle any more characters than absolutely necessary. Rainer ___ 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] syslog WG Timeline
The schedule sounds fine to me, but I can offer only limited availability (both for comments and editing) in the next weeks (chairs are notified about the specifics, I do not like to post absence information publically). Thanks, Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 1:17 PM To: [EMAIL PROTECTED] Subject: [Syslog] syslog WG Timeline Hi Folks, David and I have agreed upon a timeline for the completion of our milestones. Please review this. We will be asking for people to provide review comments on each of the documents while they are in Working Group Last Call (WGLC). If you know that you're going to be unavailable (summer vacation) for some of these WGLCs, please submit comments to the WG beforehand, at least to let us know that you've read it. Thanks, Chris and David ===start=== Aug 11 - Drive discussion on whether draft-ietf-syslog-device-mib represents WG consensus on what needs to be managed in -protocol-, -udp-, -tls-, and -sign-. Aug 11 - Drive discussion on whether draft-ietf-syslog-transport-tls should use byte-counting, special character, or both, including which special character. Aug 14 - Begin WG Last Call for draft-ietf-syslog-protocol (45 pages) Aug 14 - Begin WG Last Call for draft-ietf-syslog-transport-udp (10 pages) Aug 18 - Decide what needs to be changed in draft-ietf-syslog-transport-tls to represent the final WG consensus on byte-counting, special character, or both, including which special character. Aug 18 - Decide what needs to be changed in the general design of draft-ietf-syslog-device-mib to represent the WG consensus. Aug 28 - Close WG Last Call for draft-ietf-syslog-protocol Aug 28 - Close WG Last Call for draft-ietf-syslog-transport-udp Aug 28 - Chairs start working on Shepherding documents for - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp Sep 1 - updated revision of draft-ietf-syslog-transport-tls, representing WG consensus. Sep 1 - updated revision of draft-ietf-syslog-device-mib, representing WG consensus. Aug 28 - Begin WG Last Call for draft-ietf-syslog-sign (33 pages) Aug 28 - Begin WG Last Call for draft-ietf-syslog-transport-tls (11 pages) Sep 11 - Close WG Last Call for draft-ietf-syslog-sign. Sep 11 - Close WG Last Call for draft-ietf-syslog-transport-tls. Sep 11 - Chairs start working on Shepherding documents for - draft-ietf-syslog-transport-tls - draft-ietf-syslog-sign Sep 11 - Begin WG Last Call for draft-ietf-syslog-device-mib (33 pages) Sep 25 - Close WG Last Call for draft-ietf-syslog-device-mib. Sep 25 - Chairs start working on Shepherding documents for - draft-ietf-syslog-device-mib Oct 16 - Chairs produce Shepherding Documents for - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp - draft-ietf-syslog-transport-tls - draft-ietf-syslog-device-mib - draft-ietf-syslog-sign Oct 23 - Final review of Spepherding Documents by the WG Nov 1 - Submit the following to the IESG - draft-ietf-syslog-protocol - draft-ietf-syslog-transport-udp - draft-ietf-syslog-transport-tls - draft-ietf-syslog-device-mib - draft-ietf-syslog-sign ===end=== ___ 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] timeline
-Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 11:33 AM To: [EMAIL PROTECTED] Subject: [Syslog] timeline Hi, Chris and I are working on a schedule to help the WG meet its deliverables. We have not yet agreed on all the specific dates because Chris is on (another) vacation, but should have a schedule posted within a few days. Here are two things we need to resolve soon. 1) whether draft-ietf-syslog-transport-tls should use byte-counting, special character, or both, including which special character. We want to finalize this WG decision by August 18. My choices in order of preferrence, in that order: 1 (best) LF as delimiter, no byte counting (because of compatibilit with existing solutions) we need to escape LF and the escape character inside MSG, NO byte-couting 2 byte-counting only 3 (worst choice) LF byte-couting (see requirements for LF at 1 Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] delineated datagrams
Bazsi, all, I am not really able to follow the thread, but let me put in an important thought. We *must* allow LF inside the message. If we do not do that, it would cause problems with -protocol. This issue has been discussed at length, and there are good reasons for allowing it. So while I vote to use LF for record delineation, I also say that this means LF MUST be escaped if present in the actual message (transfer encoding). After being decoded, LF may be present in MSG. Maybe this already has been said ;) Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 1:47 AM To: John Calcote Cc: [EMAIL PROTECTED]; 'Tom Petch' Subject: RE: [Syslog] delineated datagrams On Tue, 2006-08-08 at 13:44 -0600, John Calcote wrote: Chris, While I agree with you in principle that both forms of delineation are nice to have for interop, I _wish_ we could get rid of LF - that so limits the sort of data that can be sent in the message. My two cents... The message you send are _already_ limited as most syslog daemons replace \n character with something else as it would clobber the message file when it is written to disk. In fact leaving the CR LF characters in the message could be a security risk as that way messages can be hidden, for instance if a daemon writes the following message: This is a foo message, bar=data supplied by external entity Then the value for bar might contain CR, putting the cursor to the beginning of the line on a usual VT100 compatible terminal, and the rest of can pose as a regular log message, overwriting the previous one on the screen. Of course this can be worked around by using some form of escaping while data is written to files, but again the LF character does not remain intact. syslog-ng for instance replaces CR and LF characters in the message with a space as it comes in. I rarely heard any complaints about this behaviour. And another fact is syslog/RAW also uses LF line terminators when multiple messages are delivered in a single BEEP frame. -- Bazsi ___ 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] delineated datagrams
Andrew, -Original Message- From: Andrew Ross [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:52 AM To: Rainer Gerhards; 'Tom Petch'; [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagrams Rainer, I'm in favour of using the LF delimiter as a starting point. This way we can get something that works with Cisco PIX, Netscreen, Monitorware, Kiwi, Syslog-ng etc. Then it becomes an easy task to just wrap the session with TLS. thanks for the good comment. I just think that we should specify this for the TLS draft, only. There has been a lot of discussion on plain TCP syslog and I would not like to open that discussion again. If we have it in TLS (for good reason), the odds are probably much better to get that specified for pure TLS (maybe an informational document?), too. How do you suggest we escape the LF? As an old C hack, I suggest \LF and \\. But that of course is more of cosmetical and I have no real preferrence (just a habit...). Rainer Regards Andrew Kiwi Enterprises -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Friday, 21 July 2006 2:02 a.m. To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagrams WG, now with the consensus on moving forward with -transport-tls, I would like to re-state my thoughts on delineated datagrams: I think a compromise to get -transport-tls going is that we might actually define LF to be the end of record marker and require the message inside the frame to escape LF. That would require two characters to be escaped (of for the LF and one for the escape character itself). Such a compromise would also be consistent with what is currently done in practice. And, indeed, we could avoid the byte-counting. That would fully bring us in sync to what is done today (syslog-ng, cisco Pix, rsyslog, Kiwi Syslog, MonitorWare to name a few). I still consider this to be a non-perfect framing, but I think it would be acceptable. In the medium term, we should look into a more sophisticated framing, maybe borrowed from NETCONF. But that should come after we have delivered something. A byte-count could be prefixed to each record, but that would break compatibility with existing implementations (this is not absolutely necessary, but I consider it a very-nice-to-have, especially if the price for it is low). Comments appreciated, Rainer -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 4:17 PM To: Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagrams Tom, I think your and Anton's commetn below so far is the most important comment on -transport-tls technical issues (assuming that the certificate issue can relatively easy be fixed by specifying a cipher suite). IMHO the comment applies to any shim layer for stream protocols, not just TLS. I think a compromise to get something like -transport-tls going is that we might actually define LF to be the end of record marker and require the message inside the frame to escape LF. That would require two characters to be escaped (of for the LF and one for the escape character itself). Such a compromise would also be consistent with what is currently done in practice. And, indeed, we could avoid the byte-counting. That would fully bring us in sync to what is done today (syslog-ng, cisco Pix, rsyslog, Kiwi Syslog, MonitorWare to name a few). I still consider this to be a non-perfect framing, but I think it would be acceptable. In the medium term, we should look into a more sophisticated framing, maybe borrowed from NETCONF. But that should come after we have delivered something. If that might be a compromise, I could quickly draft an I-D that *documents* the way TCP based stream transport is used today. -transport-tls would then just need to add description of TLS handshaking. Or the I-D could be informational describing what can be found in practice. I do not know if that would have any effect on the patent office's decision (but I can claim publically-available previous work, around Jan 2003 - see http://adiscon.org/specs/selp-2003-01-15.txt). For the legal folks: I have running implementations and public documents describing the method outlined above. It is fraudulent if somebody claims he has invented the method I have described here, at least if he hasn't invented it roughly 10 years or so ago. Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 11:47 AM To: Anton Okmianski (aokmians); [EMAIL PROTECTED] Subject: Re: [Syslog] delineated datagrams inline - Original Message - From: Anton Okmianski (aokmians) [EMAIL PROTECTED] To: Tom Petch [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June
RE: [Syslog] delineated datagramswasdraft-ietf-syslog-transport-tls-01.txt
Miao, I agree with your comments. However, using the LF as a record delimited would still allow us to interop with existing syslog/tls implementations. This is my major point. I think it is worth it. Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 12:00 PM To: 'Tom Petch'; [EMAIL PROTECTED] Subject: RE: [Syslog] delineated datagramswasdraft-ietf-syslog-transport-tls-01.txt TLS uses SHA-1 or MD5 in ciphersuite for message integrity verification. If bytes lost happens during transferring, the message will be dropped by TLS. That is also the cause that we need a security mechanism for Syslog. As for error of encoding/decoding, I believe if an application does encoding/decoding in a wrong way, you must not expect it do it right with other mechanism, such as LF. Redundancy to improve robustness is good idea, but I don't think it applies to this case. -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:43 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] delineated datagrams wasdraft-ietf-syslog-transport-tls-01.txt I wonder if others share my concern about the lack of robustness in the way in which datagrams are delineated in the stream protocol (a TCP rather than a TLS issue). The system works as long as - the frame length is encoded perfectly - the frame length is decoded perfectly - no bytes are inserted or removed in error which is doubtless true in some networks, but I would prefer not to rely on it. So, when an error occurs, can the Collector/Relay detect it? Can the Collector/Relay recover synch? If not, what does the Collector/Relay do? There is very little redundancy in the definition of frame length, and syslog messages have very little structure to help the application, so I think that this is an issue we should address. Tom Petch - Original Message - From: David B Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG [EMAIL PROTECTED] ___ 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] syslog over ssh
Hi WG, I just wanted to let you know that I have posted the individual submission on syslog over ssh: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg11360.html I have done this idependendly of the transport-tls issue. It is, at best, loosely connected (in that the work was spawned out of that discussion). I think the idea of syslog over ssh is generally worth thinking about and it is not implying that I expect -transport-tls to be discarded. I am still of the opinion that work in that area should progress (vote A). Please read the draft in that spirit. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Decisions to make about the Huawei IPR claim
Tom, I do not know if rewriting really helps. I suspect Huawei's patent lawyers, like patent lawyers everywhere, did a good job in wording the patent application so generally that probably evertyhing we do in respect to syslog/tls would fall under their claim. Eventually, that would even apply to anything that securely transports syslog. You do not know without the claim details. I'd guess it says something like transporting system logs over a secure channel ;). My personal opinion is that we should continue with -transport-tls, Chris' A) option. My reasoning: 1. the proposed licensing terms look fair enough to me 2. the patent is probably quite trollish and it is questionable if a) it will be granted at all b) survive appeal (if somebody appeals) 3. I'd like to see documented and standardized a tls transport as it is already in use today. This hopefully helps getting it quickly implemented. A technical issue regarding 3: I know that the current approach is flawed. Maybe I do not see all the seriousness of it. I still think it is good enough as a starting point, bringing together what is done in practice already. Once we are finished with transport-tls, we can look into better alternatives. One such is 3195bis, the other -transport-ssh. -transport-ssh probably has most potential when it comes in trying to converge different NM protocols. But we could also end up defining no separate transport but using NETCONF notifications with a syslog event message data model. I do not know how to prevent that your comments (and mine and anybody elses) comment become part of Huawei's IP. Maybe it would help to publish them as a separate document, if the volume justifies that. All in all, I still go for option A) as the best compromise. This is made on the understanding that we do *not* modify/enhance -transport-tls much further (just the bare necessities). This argument is based on my we must publish POV. Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 9:56 AM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim inline Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: Darren Reed [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 6:25 PM Subject: Re: [Syslog] Decisions to make about the Huawei IPR claim Hi Darren, There is no need for Bazsi to write a different i-d. draft-ietf-syslog-transport-tls is a Working Group document and the final revision must reflect WG consensus. I think that draft-ietf-syslog-transport-tls is seriously flawed and I have already made some comments on this, have others pending. But I am now reluctant to make any constructive suggestions lest my text be slightly modified, incorporated into this I-D and then made subject to an IPR claim. I believe we need a new document, or at least a new editor who is prepared to rewrite everything. I am not saying it should be that of Bazsi, just anyone who does not have H*** in their e-mail address. Tom Petch If Bazsi (or anybody else) can propose changes to draft-ietf-syslog-transport-tls and the WG reaches consensus on the proposed changes, then the document will be revised to reflect that. Please check me if I'm wrong on this, but I think that the only changes between syslog-ng and what's in syslog-transport-tls are - framing, - changes to address the threat model (listed in our Charter). 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] draft-ietf-ipcdn-pktc-eventmess-07.txt
I wonder if all the references to RFC3164 should be revisited in the light of Rainer's work on syslog-protocol, or is this an environment which is accurately described by RFC3164? The current DOCSIS and PacketCable syslog agent/server environments are accurately described by RFC 3164. Small, (but important?) glitch: RFC 3164 is informational, so you can't use it as a normative reference. Other than that, I've not been able to check much more. So I can't judge if that poses a problem. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Decisions to make about the Huawei IPR claim
David, I fully agree with your thought. I, too, think we must put emphasis on the delivery of documents. In my personal opinion, this leaves only two realistic options: a) rfc 3195bis as you have described it (without the rathole discussion) b) -transport-tls more or less as it is now I think there are enough comments on a) already in the list archive. I will not repeat them. Comments on b) currently tend to focus on the IPR issue. Let's ignore that for a moment and look at other arguments. We have intially opted in favor of -transport-tls because it already is in widespread use. What is done currently can not be standardized literally, but we can standardize something that is quite close to it. It was our opinion that -transport-tls should by fairly easy to implement, thus bringing some immediate value to the community. Now some technical issues have come up on the list, things like app-layer ACKs, opening and closeing conversations. I have brought up some of them. I am also of the view that we could craft a better framing, probably borrowing from NETCONF (and thus easing conversion - the big picture). This is still sufficiently easy, but it is a big departure from the let's standardize what is used in practice approach. I fear that discussing a better framing/session management again takes up a lot of time and includes a high risk of missing our milestones again. BTW: we are scheduled to deliver by November 2006, and I do not expect that we will be granted an extension this time again. November will be very soon, especially looking at the summer break. So I propose that we do NOT enter any new discussion. We should deliver either a) or b) (above), without introducing any new features or ideas. That means that the result will be sub-optimal. But delivering something usable is much better than aiming for the perfect one that will never appear. Once we have delivered, we should discuss what to do next (but only AFTER delivery). I have to admit that I now see some good points in a -transport-ssh and consider it implementable with reasonable effort. However, -transport-ssh should be done after we have reconsidered the framing. Given the track record of this WG, I would suspect this can not be done in less than 12 to 24 month. There are also the issues that Anton brought up and the general question on configuration and event data models for syslog. A lot of useful work lying ahead (but depending on our ability to finish the base stuff first). I think this work can never be done if this WG fails. So I am desperately trying to get us to publish. I think what we have is useful and well-enough. If we do not publish soon, we will never be able to publish at all. IMHO, we have already received our third chance and there will be no fourth... Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Thursday, June 29, 2006 8:32 PM To: Rainer Gerhards; 'Chris Lonvick'; [EMAIL PROTECTED] Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Hi Rainer, [speaking as a contributor] This WG needs to deliver documents soon or the WG could be closed. We need to deliver a secure transport solution. If the WG decides to do a 3195bis as the secure transport solution, I recommend the short-term deliverable be good enough to work with syslog-protocol. That way we can get 3195bis AND the other documents (-protocol- and -udp-) published and onto the standards track, so the industry can begin to implement, and the WG can stay open to do additional work. Then we can address whether the 3195 design should be modified in other ways. There have been suggestions to modify 3195 to harmonize with the work of other Standards Development Organizations such as OASIS and W3C. Doing that work would likely not be quick or easy. I fear it would be a real rathole that would prevent us getting 3195bis published at all, and if 3195bis is the WG's choice as the secure transport protocol, then that rathole would also prevent the publication of -protocol- and -udp- on a timely basis. As a 14-year veteran of IETF WG efforts, I think it would be a bad WG decision to put 3195bis on the critical path and to open it up to a rathole discussion. If 3195bis is on the critical path, we need to avoid the rathole discussion for now; it can be considered for a future release. If the WG feels the rathole discussion is really necessary, and 3195bis should not be done without having had such a possible-rathole discussion, then 3195bis should not be put on the critical path. My $.02 David Harrington [EMAIL PROTECTED] -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, June 29, 2006 5:11 AM To: Chris Lonvick; [EMAIL PROTECTED] Subject: RE: [Syslog] Decisions to make about the Huawei IPR claim Besides the somewhat political issue, I think there is also technical issue that affects the question. I think we
RE: [Syslog] IESG secure transport requirement can be quicklysolved...
Hi David, thanks for the advise, I will do as suggested. I am currently thinking about the framing used inside the session. Once ready, I will publish it on my website and send a link to the WG. I would appreciate, though, some feedback on the overall picture based on what I currently have: http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-ssh-00pre.t xt Thanks, Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 6:22 PM To: Rainer Gerhards; 'Chris Lonvick' Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... Hi Rainer, The deadline for a -00- draft has just passed, so you won't be able to publish officially until after Montreal. I recommend posting the draft to the mailing list for discussion, as a non-WG draft. By the time the I-D publication process re-opens after montreal, the WG can decide whether to have you publish as an individual or WG draft. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 11:09 AM To: David Harrington; Chris Lonvick Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] IESG secure transport requirement can be quicklysolved... David, WG, -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] [snip] It is important that we make progress and not just discuss the alternatives, ad infinitum, however. We need volunteers who are willing to put in the work to write viable internet-drafts and drive them to completion, or the discussions are largely useless. So, I will make these requests to help focus the discussions: 1) please indicate which secure transports you consider to be feasible, -transport-ssh, rfc3195bis, [-transport-tls] 2) please indicate which secure transports address which syslog threats (they're listed in syslog/tls), section 2 of -transport-tls, IMHO, applies to all three 3) please indicate which secure transport you volunteer to write a draft for, and I have acutally written (copypaste plus a few sentences) something that could be a starting point for -transport-ssh: http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-transport-s sh-00pre.t xt If it is WG consensus, I can submit this as an WG document. The current version describes the overall picture plus a weak idea of framing and transmission (sections 4, 5, and 6). This idea was taken from the current discussion on -transport-tls. However, I consider it to be very insufficient and have made no attempt to specify it in depth. If we adopt this document, I would further investigate how a proper framing would look like. I have on my mind to borrough some ideas from netconf, but use them in the simple spirit of syslog (e.g. we might use the same opening with a syslog-reserved URI, if the netconf-WG does not object against this, but it is too early to discuss such issues). I would also volunteer to update 3195 to 3195bis, if their original authors are not available for that. I expect to need some help on the XML schema when doing so. As I have already written, I expect this to be an extremely easy and quick task. My summary in the other mail was concluding. There is no need for any additional edits. 4) please indicate which secure transport you would commit to implement in your products (and do you have the decision-making authority to commit what gets implemented in shipping products?). With a very high probability, we would implement -transport-ssh and with a somewhat lower probability we would change our rfc 3195 implementation to support 3195bis. I would expect this to happen in our products as well as in liblogging/rsyslog (open source projects). I have sufficent decision-making authority to make this commitment (not thinking about major market or overall company policy changes). I would deeply appreciate feedback if I should submit the -transport-ssh draft as a WG document. Rainer Disclaimer: products do not need to be commercial products; they can be freely available implementations, such as open source libraries. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 10:05 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] IESG secure transport requirement can be quicklysolved... Hi Everyone, On Tue, 20 Jun 2006, Rainer Gerhards wrote: I would appreciate if the chairs could try to reach consensus on my proposal. Comments
RE: [Syslog] Secure transport alternatives
Miao, technically, I agree with you. HOWEVER, I need to point out that your company is the root cause of the problem. The IPR rights claimed on your transport-tls document have taken it hostage. Even though the licensing terms seem reasonable (which needs to be prooven in undisclosed detail), there honestly is nothing novel in the draft. Your legal department is not even telling us which section is claimed to have been invented by Huawei. The simplest and most productive way to solve the current issue is make your legal department drop the patent claim. My understanding is that it can be easily challenged (for those with big legal departments...) so it will probably be without substance, too. You should also talk to your legal department and superiors that Huawei's peformance in this WG is costing Huawei a lot of its goodwill in the community and probably even in the end-user space. For example, the largest German IT-Site (Heise press[1]) has carried a story about Huawei's move and Huawei has not made a good picture in the user feedback. I also promise that I personally will try to get more press coverage of this move. It is one thing to secure one's intellectual property. It is another thing to be a patent troll. And it is yet another thing to be a patent troll who steals other people's work. I have to admit that I consider Huawei (as far as the syslog WG is concerned) to be part of the third camp. Get *that IPR issue* solved and the technical issue is solved, too. In the mean time, we try to provide an open standard. RFC 3195bis seems to be the most appropriate choice here, because it can't be taken hostage by another abusive patent claim as it bases on well-defined prior art (RFC 3195). Far more important standardization efforts have been brought to a hold by IPR claims (think: SPAM). Claiming IPR where there are none is of no utility. Huawei needs to learn this. [1] http://www.heise.de/newsticker/meldung/74342 (in German) Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 7:49 AM To: 'David Harrington'; Rainer Gerhards; [EMAIL PROTECTED] Subject: RE: [Syslog] Secure transport alternatives Hi, IMO, most current security protocols(TLS, DTLS, SSH, IPsec) provide similiar security service for application, such as confidentiality, integrity, anti-replay and peer identity authentication. In the same time, most of the applications share similiar security threats, such as hijacking, MITM, falsification, eveasdropping etc. So, it may does make much sense to invest too much effort on evaluating/matching security threats and service. In the same time, most current security protocols come from security mechanisms specific to some applications. For example, SSL was designed to secure HTTP, SSH is an application protocol for interactive shell command. They are not real general security mechanisms(except IPsec, but it is not application-friendly). So, IMHO the primary criteria for selection is: is it convenient for the application to invoke the security service provided by the security protocol? Taking convenience in mind: the order may be: DTLS - TLS - SSH - BEEP(?) - IPsec From an implementer's perspective, I think DTLS costs the least effort to implement, TLS second. I have not much idea on how much SSH and BEEP take, but I believe it cost more than DTLS/TLS. There is few RFC3195 implementation, it sounds bad to revive an market-abandoned solution to just satisfy IESG. IPsec? It costs the specifcation and program developer nothing, but it costs too much to provision, never a good solution for Syslog. My 1 cent! Miao -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 1:58 AM To: 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: [Syslog] Secure transport alternatives Hi, [Posting as a contributor] I am involved in a number of NM and Security WGs, and I can make these observations: Running an NM protocol over SSH has been done in both netconf and ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH draft to work for syslog-over-SSH. I suspect it would take a week or so to write a syslog-over-SSH draft since most could be cut-and-paste from the netconf-over-SSH draft. I am the author of the ISMS drafts, and I adapted the netconf/SSH draft for ISMS purposes. Syslog and netconf seem to be closer in their requirements than syslog and ISMS. ISMS has this whole model of access control to deal with that is not part of the threat model for syslog or for netconf at this time. There is a parallel discussion of running syslog messages over netconf. As Rainer has pointed out to Phil, having a consistent terminology would be very helpful. I think having a consistent security solution would probably be helpful in that situation as well
[Syslog] Huawei IPR claim
Hi all, I think I have some good news. Huawei has updated its IPR disclosure. Please see https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724 The license has dramatically been changed: ** If technology in this document is included in a standard adopted by IETF and anyclaims of any Huawei patents are necessary for practicing the standard, Huawei will not assert any patents against any party that implements the standard, however that Huawei retains the right to assert its patents against any party that asserts any rights against Huawei; and Huawei retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. ** I am a bit stunned that Huawei updated the disclosure silently (on the 20th). I am a bit puzzled if another update might again impose more stringent terms. I still think the patent itself is theft of other person's work. Unfortunately, the disclosure still does not mention which section of the I-D is threatened by the patent. But the change is a very welcome one and I wanted to make you aware of it. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Secure transport alternatives
Tom, I have to admit I have overlooked this item. I agree that we (especially me) were very TLS-minded. My memories tell me we intentionally left the door open for other transports, but I may be wrong. As it looks, I need to re-visit the mailing list archive. I hope I will be able to do so soon. I also have on my mind that we intended to do 3195bis after tls was finshed, so we did not plan to totally abandon it. Again, all of this out of my memory... Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 12:03 PM To: Rainer Gerhards; David Harrington; [EMAIL PROTECTED] Subject: Re: [Syslog] Secure transport alternatives Rainer Looking at the outstanding milestones, I see Nov 2006Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Nov 2006Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD which is why I see TLS as embedded in the charter (as well as, more obscurely, in the discussions that led up to the charter change). Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: Tom Petch [EMAIL PROTECTED]; David Harrington [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 22, 2006 10:48 AM Subject: RE: [Syslog] Secure transport alternatives Tom, But, in all seriousness, changing from TLS to anything is a charter change that I think needs the approval of the IESG, and should require commitment, similar to that given at the turn of the year, to produce conformant products. I do not agree here. We have deliberately not used the term TLS in the charter. The relevant excerpts are: ### The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. ### ### - A document will be produced that requires a secure transport for the delivery of syslog messages. ### As far as I remember (not looked up the archive yet), we did this intentionally so that we could change transports if need arises. At least for now, I think this need has arisen. The really bad thing about the IPR claim is that we do not even know what actually has been claimed. But I do not intend to invest any of my work into something that somebody else claims exclusive rights on. So -tls is a dead end for me as long as the claim is not dropped. I foresee similar harsh reaction at least of the open source commuity (*the* major driving factor behind syslog implementation) when we standardize something encrumbered by a patent. Rainer Tom Petch - Original Message - From: David Harrington [EMAIL PROTECTED] To: 'Rainer Gerhards' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 7:58 PM Subject: [Syslog] Secure transport alternatives Hi, [Posting as a contributor] I am involved in a number of NM and Security WGs, and I can make these observations: Running an NM protocol over SSH has been done in both netconf and ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH draft to work for syslog-over-SSH. I suspect it would take a week or so to write a syslog-over-SSH draft since most could be cut-and-paste from the netconf-over-SSH draft. I am the author of the ISMS drafts, and I adapted the netconf/SSH draft for ISMS purposes. Syslog and netconf seem to be closer in their requirements than syslog and ISMS. ISMS has this whole model of access control to deal with that is not part of the threat model for syslog or for netconf at this time. There is a parallel discussion of running syslog messages over netconf. As Rainer has pointed out to Phil, having a consistent terminology would be very helpful. I think having a consistent security solution would probably be helpful in that situation as well. I have concerns about 3195bis as the only alternative we consider, because I have not seen much interest in RFC3195 yet, nor has there been much expresseed interest in netconf over BEEP. Since there may be delay
[Syslog] RE: Secure transport alternatives
David, Hi, [Posting as a contributor] I am involved in a number of NM and Security WGs, and I can make these observations: Running an NM protocol over SSH has been done in both netconf and ISMS. I suspect it would be fairly easy to adapt the netconf-over-SSH draft to work for syslog-over-SSH. I suspect it would take a week or so to write a syslog-over-SSH draft since most could be cut-and-paste from the netconf-over-SSH draft. I have gone throught the netconf-over-ssh draft with syslog on my mind. I agree, it should be fairly easy to adapt. I am the author of the ISMS drafts, and I adapted the netconf/SSH draft for ISMS purposes. Syslog and netconf seem to be closer in their requirements than syslog and ISMS. ISMS has this whole model of access control to deal with that is not part of the threat model for syslog or for netconf at this time. There is a parallel discussion of running syslog messages over netconf. As Rainer has pointed out to Phil, having a consistent terminology would be very helpful. I think having a consistent security solution would probably be helpful in that situation as well. I have concerns about 3195bis as the only alternative we consider, because I have not seen much interest in RFC3195 yet, nor has there been much expresseed interest in netconf over BEEP. I agree it is questionable if RFC 3195 will succeed. I have seen some companies (also at least one of the big guys) make investment in 3195. I am not sure if it simply is too early to abandon it. If we do not want to abandon it, we need to create a 3195bis, because 3195 will not be usable together with syslog-protocol (because it mandates a different format). Since there may be delay involved in this WG no matter what, would somebody be willing to volunteer to write a syslog-over-SSH draft, so the WG can compare the three approaches? After my review, I think I am able to do that. So I volunteer. There are other possibilities as well (and I am being serious here, not let's make this absurd by proposing a whole slew of alteratives documents). 1) Tom mentioned DTLS, which might be a viable alternative given syslog's UDP roots. Tom would you, or somebody else, be willing to write a proposal for syslog/DTLS? 2) Andy Bierman observed that if syslog messages are going to be transported over netconf, then why not simply use syslog/netconf and let netconf deal with the security issues. That could be an alternative proposal. Is anybody willing to write a draft proposing that as a syslog secure transport solution? I, too, think this is an option. Wouldn't it be sufficient to adopt draft-shafer-netconf-syslog-00.txt as a WG document? (Provided Phil would be happy with that...). I guess that would obviously involve some coordination between the syslog and netconf WG, which I hope is not a big problem. Rainer My $.02 as a contributor, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 9:44 AM To: [EMAIL PROTECTED] Subject: [Syslog] IESG secure transport requirement can be quickly solved... Hi all, I propose to update RFC 3195 in the spirit of syslog-protocol to satisfy the IESG secure transport requirement (I will call this derivative work RFC3195bis below). I sincerely believe that this option would enable us to submit syslog-protocol, -transport-UDP and RFC3195bis within a few weeks. My reasoning for this proposal is as follows: We all know that 3195 has limited acceptance in the community and very few implementations. However, it satisfies all IESG criteria we have in our charter. Also, it *is* something that can be used in practice and implementing it becomes easier as support libraries become visible. I know it is not an optimal choice. On the other hand, we have syslog-transport-tls, which has been encrumbered by a patent claim. As it looks, this will need months to solve. RFC3195bis can not be taken hostage by any patent claims, because there is well-defined prior art in RFC 3195. Focussing on RFC 3195bis would enable us to complete our mission and finsh work that is in the queue for many years now. I think this is urgently needed. We might even put the netconf WG with their syslog gateway on hold (because syslog-protocol can not be published without resolving the secure transport). Or netconf might choose to drop syslog-protocol in order to publish. And the good news is that 3195bis can definitely very quickly be done. I am saying this on the assumption that we do not revisit the basics of 3195 but just adopt it to syslog-protocol. I've gone through 3195 today and the changes are absolutely minimal: Section 2: Most of it simply needs to be removed because the entity roles are defined in syslog-protocol. Section
[Syslog] FW: draft-shafer-netconf-syslog-00.txt
Hi all, This posting from the netconf WG seems highly relevant. The page itself uses some crumbersome challenge system, so I could not look at the actual content. I will do so when the draft is posted on the IETF site and recommend that other WG members do so, too. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Shafer Sent: Saturday, June 17, 2006 6:07 AM To: netconf Subject: draft-shafer-netconf-syslog-00.txt I've finally got an initial version of the draft for a netconf capability that makes syslog data available over long-lived RPCs. I just sent it off to the RFC Editor, so it should show up on ietf.org sometime this weekend, but an advance copy is available. http://professional.juniper.net/phil/ietf/draft-shafer-netconf-syslog-00 .txt Thanks, Phil -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/netconf/ ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt
I agree with Tom that a TCP document would be useful and probably needed. Before someone from Huawei comes along and tries to patent this, too, I volunteer to write this document... Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 10:13 AM To: [EMAIL PROTECTED] Subject: Re: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt I think that this document has some way to go. It has introduced, and woven together, both TLS and TCP transport, which I think wrong. Ideally, I think that we should have two separate documents, one dealing with TLS, the other with TCP issues; given that both would be short, it is probably sensible to have only the one, but I still see the need for separation within the document. After all, DTLS exists: an outsider could, should, think that syslog is UDP-based, DTLS provides UDP security so DTLS is the obvious choice, what on earth is this document talking about? We need a section on DTLS (if only justifying why it is not for further consideration). And, for me, that alone justifies teasing out the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. That said, I do not think that this document adequately covers the TCP issues, ones that have surfaced on the list before. TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog message or a combination thereof - it is in the nature of a stream protocol. This needs spelling out. A TCP connection takes time to set up, TLSoTCP longer. This needs spelling out; if timely delivery is a concern, then the connection should be established in advance. The section on TCP termination is too weak. If we are recommending a timeout, then we should recommend a value, even specifying that it should be configurable over a range. And if we cannot agree on such values, I do not think we should be specifying a timeout. TCP perforce introduces flow control. This will slow down and rate limit messages; what is the impact of this on the application? TCP failures can terminate the connection! Again, this has an impact on the application with the time taken to become aware that the connection has failed. Tom Petch - Original Message - From: David B Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG [EMAIL PROTECTED] ___ 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] stream transportwasdraft-ietf-syslog-transport-tls-01.txt
Oh... and, yes, there is prior Art: This spec was openly discussed some years ago on the loganalysis mailing list. While the text itself can not be used nowadays, I think it conveys many things that need to be considered. http://www.monitorware.com/en/workinprogress/selp.txt Rainer -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 11:28 AM To: Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt I agree with Tom that a TCP document would be useful and probably needed. Before someone from Huawei comes along and tries to patent this, too, I volunteer to write this document... Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 10:13 AM To: [EMAIL PROTECTED] Subject: Re: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt I think that this document has some way to go. It has introduced, and woven together, both TLS and TCP transport, which I think wrong. Ideally, I think that we should have two separate documents, one dealing with TLS, the other with TCP issues; given that both would be short, it is probably sensible to have only the one, but I still see the need for separation within the document. After all, DTLS exists: an outsider could, should, think that syslog is UDP-based, DTLS provides UDP security so DTLS is the obvious choice, what on earth is this document talking about? We need a section on DTLS (if only justifying why it is not for further consideration). And, for me, that alone justifies teasing out the TLS issues from the TCP issues; is FRAME-LEN needed over DTLS?. That said, I do not think that this document adequately covers the TCP issues, ones that have surfaced on the list before. TLSoTCP can deliver one syslog message, many syslog messages, part of a syslog message or a combination thereof - it is in the nature of a stream protocol. This needs spelling out. A TCP connection takes time to set up, TLSoTCP longer. This needs spelling out; if timely delivery is a concern, then the connection should be established in advance. The section on TCP termination is too weak. If we are recommending a timeout, then we should recommend a value, even specifying that it should be configurable over a range. And if we cannot agree on such values, I do not think we should be specifying a timeout. TCP perforce introduces flow control. This will slow down and rate limit messages; what is the impact of this on the application? TCP failures can terminate the connection! Again, this has an impact on the application with the time taken to become aware that the connection has failed. Tom Petch - Original Message - From: David B Harrington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 09, 2006 4:26 PM Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt Hi, A new revision of the syslog/TLS draft is available. http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 .txt We need reviewers. Can we get 1) a person to check the grammar? 2) a person to check the syslog technical parts? 3) a person to check compatibility with the other WG documents? 4) a person to check the TLS technical parts? We also need general reviews of the document by multiple people. Thanks, David Harrington co-chair, Syslog WG [EMAIL PROTECTED] ___ 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] stream transportwasdraft-ietf-syslog-transport-tls-01.txt
Anton, the ACK should only be from hop to hop - much as in SMTP. It is a method to know if the data has arrived at the next receiver. I think it probably is worth it. I can live without the ACK, but I think a defined closure is needed. An initiation exchange I consider useful, but again not mandotory. Rainer -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 5:50 PM To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt App-layer ACK is an interesting idea, but I think it opens up a big discussion. Does the relay ACK? Overlap with RFC 3195 (syslog-beep). Overlap with SNMP Informs. Etc. Anton. -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 11:36 AM To: Anton Okmianski (aokmians); Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt Anton, -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 5:25 PM To: Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt I was just talking to Rainer about similar concern. You were, but I misunderstood it. I was so focussed on the (objected) plain tcp transport, that I did not realize that you were actually talking of a layer between -protocol and -transport-whatever-secure. I think first of all we need a basic mapping to TCP or more generally define syslog payload (framing) format for connection-oriented protocols. This should cover sending multiple messages over the same connection, obviously. The same payload structure can be used over various TCP protocols (TLScTCP, SSHoTCP, etc) or even over straight TCP with IPSec. Connection establishment and tear-down issues should be left to the actual transport. I think it shouldn't. I actually think we need an app-layer ACK, otherwise we might loose messages without knowing it. This is from the SELP spec I posted earlier: === As such, SELP is only reliable as far as the TCP stream is not broken. If the TCP stream breaks, the sender does not exactly know which data has actually been transmitted to the receiver and which not. This is due to the fact that TCP uses a sliding window of variable size. In short, this allows that the sender sends packets, receives an acknowledgement from the OS, but the data is still on the wire. The OS acknowledgment does NOT mean the data is actually received. While the sender continues to send data, the already OS acknowledge data is eventually delivered to the sender. If that succeeds, everthing is fine. If now, however, the TCP stack will detect the problem over time and notify the sender. However, the sender does not know exactly where the problem occured and so does not know what to re-send. Anyhow, it knows at least something went wrong and SHOULD log an event to a local system event repository. == I think we should address this need in a tcp (or better: stream) framing. It's not a big deal to add an app-level opening and closing to the protocol - and eventually even an app-level ack/nak (per message), which would relive us of many problems. It can be as simple as Sender: XFERSTART sender-name (could be checked against cert!) MSG headerprotocol-messagetrailer (trailer for error-checking, questionable) CLOSE optional-param Receiver: SMTP-like status codes (or simply ACK / NAK reason) No a big deal but a big advantage... If we don't introduce anything new in TLS or SSH, I am not sure why anything extra is needed to be specified. Maybe just to create a baseline of requirement (minim cipher suite, auth mode, etc), but even that is questionable. I think the parameters should be outlined. BTW, can IPSec be considered a viable security transport for syslog using UDP transport? I already mentioned how IPSec can address security issues in syslog-transport-udp-07. So, do we simply need to provide an overview of how it does it in that ID to pass the IESG criteria of secure syslog transport? This is a very good question, I think one for Sam. Maybe Chris could check it out? Rainer Thanks, Anton. -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 4:13 AM To: [EMAIL PROTECTED] Subject: Re: [Syslog] stream transport wasdraft-ietf-syslog-transport-tls-01.txt I think that this document has some way to go. It has introduced, and woven together, both TLS and TCP transport, which I think wrong
[Syslog] draft-ietf-syslog-protocol-17 submitted
Hi all, I have just submitted this draft. It is a minor update over the previous version. Most important points for publishing: - -16 expires soon - truncation rules releax - no handling of Unicode etc required (as discussed on list) - langauge brush-up by Chris Lonvik (thanks again, Chris!) Contrary to what was discussed early this year, -17 does not reference nor require transport-tls. I have removed this reference because Sam indicated we might submit -protocol without -transport-tls. Further, I find it highly questionable if -tls will ever find acceptance in this WG given the IPR claim. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Having IPR in IETF Documents
Chris, ok, you have pointed to the IPR IETF list, anyhow, one comment on this list is due: I do want to be clear on this subject. Hauwei is well within their rights to discover something while writing a Working Group document, and then to claim IPR on that discovery. This has happened in the past which was why the IETF started writing BCP 79 - currently RFC 3979. The discussion of the use of IPR in IETF documents has been very rocky but overall, the IETF is really just catching up with other standards developing organizations. Almost all other standards organizations have developed clear rules about bringing IPR into their documents and the IETF has done the same. There might (might!) be some reasoning for this in some cases. In our case, this is more than frivolous. I thought Huawei claims something the have invented before writing the tls document. If it really belongs to the document - I actually feel I shall be ripped of my work. I've just scanned the 3 (!) core pages of syslog-tls. It is nice to hear that Huawei has discovered how tls works. The only novel thing in the pages is using a byte-counted header. I think I can claim IPR on that because I introduced it in the -tls discussion (of course other people introduced this concept too, but I was the first one to apply it to syslog ;)). Huawei didn't even initially understand how this was supposed to work, so I and others (namely Anton, who could also start the patent race...) needed to explain in detail. Other than these things, there is not even any technical content in the document. It's a stupid simple protcol mapping. I am upset. I think I need to consider applying for a patent on the layered architecture for syslog as well as for using structured data. Sounds silly? I think it's less silly than what Huawei seems to claim. Probably I go for that. Folks, this is not the way I like to work. I have to re-word my mail from yesterday. In this case, Huawei actually seems to *abuse* an already *abusive patent system*. I have no understanding for this and I have a hard time understanding those folks that think this is the right course of action. I am not against patenting *invention* in a general sense. But I would like to see something *invented* (that means you design something that is *new*, aka did not exist before). And I definitely do not like to see that my work is stolen by someone else. I've contributed to this WG in the thought that would lead to a freely usable open standard. Looks like the GPL folks are actually right... If the claim is actually arisen out of -transport-tls, I will no longer work with the authors of this draft. I ask the WG to look for some other authors. I am staying tuned if the claim actually *roots* in -transport-tls. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
Hi all, I agree with Anton on all important issues. I've read the IPR claim and what disturbs me the most is unpublished pending patent application. This sounds like someone took what we have been discussing (and is widely deployed), brought it to a lawyer and is now trying to make some patent out of it. This smells very bad. Without knowing what exactly is claimed to be invented by the claimer, I can not judge the effect it will have on my work. Anyhow, I do not intend to invest any of my time into something that somebody else claims exclusive rights too. If I did, I'd end up with the need to pay (money-wise or other) for the right to use my own work. Would I be smart if I did that? ;) The licensing terms themselves sound fair (but are vague enough to do so...). My root concern is that there is nothing that has been invented by that party. I am still waiting for someone to patent the use of the letter a (@ has been tried AFIK)... I think using a patented technology inside a standard will definitely hinder the acceptance of that standard. Especially if it is something as trivial as syslog over tls. So my vote is to put this work on hold until further clarification can be obtained. If that means we'll have no syslog RFC, so be it. That would probably be the better choice... Rainer -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 11:26 PM To: David Harrington; [EMAIL PROTECTED] Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Royalty-free does not generally mean free! It means you don't charge per-end-user, per-server fee. But it does not mean there is not fee. Plus, license terms suggest other reasonable, non-discriminations terms and refer to reciprocal license needed to implement standards. Notice plural. I know the giants like Cisco and Huawei will find a common ground as they can sue each other silly with their patent portfolios. My concern is more from the perspective of having an open standard for everybody to use. I think some companies will be reluctant to use it given a law suit threat or the hustle of extra licensing. I think clarification on what is claimed are in order before investing more effort into this. Anton. -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 3:14 PM To: [EMAIL PROTECTED] Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Hi, Three things: 1) Whether the patent would survive a check into prior art is not something the IETF takes a position on: Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [EMAIL PROTECTED] 2) The company has filed a disclosure. You should read the disclosure before losing your cool. The disclosure says (roughly) it will license the technology royalty-free for standards use. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=717. 3) Since I work for the company filing the disclosure, I will recuse myself from chairing this discussion. I have asked Chris to chair the discussion. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ 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] Draft-ietf-syslog-transport-tls-01.txt
Hi, I have been told that Huawei patents date back no longer than 2001. This seems to confirm it: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=2u =%2Fnetahtml%2FPTO%2Fsearch-bool.htmlr=0f=Sl=50d=PG01s1=HUAWEIPage =NextOS=HUAWEIRS=HUAWEI Also, David said I believe the applicant is permitted to not disclose the claims for eighteen months.. Assuming this holds true, and speaking only of US patents, this seems to mean that the patent in question can not date back to later than 2004. In contrast, Google has a newsgroup post about syslog-ng and stunnel from 1999: http://groups.google.com/group/comp.security.unix/browse_thread/thread/d 125f044c5f8ba4a/6c87c15ddff26516?lnk=stq=syslog-ng+stunnelrnum=118#6c8 7c15ddff26516 I guess there are many more samples of prior art (e.g. during the formation of this WG, some texts I wrote myself in 2004, many more howtows pre-2000 and probably stunnel changelogs and installations). This all brings me to the conclusion that this is not only insane but mostly irrelavant. Of course, someone needs to object the patent if it is awarded (which unfortunately seems to be more than possible). The question is who will do that (and what it costs). But besides that, there should be no problem. What a rotten system the patent system has become... Back to on-topic: I think we can continue with -transport-tls, though I have to admit I am still hesitant to put too much effort into it myself. Probably those claiming rights should also do at least a little work on it ;) Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:27 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt Hi, On Thu, 8 Jun 2006, Balazs Scheidler wrote: On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote: Rainer I think using a patented technology inside a standard will definitely hinder the acceptance of that standard. Especially if it is something as trivial as syslog over tls. So my vote is to put this work on hold until further clarification can be obtained. If that means we'll have no syslog RFC, so be it. That would probably be the better choice... Bazsi My feelings are about the same. I don't really know the US patent system specifics, how long does it take to have something concrete about the patent? [Minor note: I don't think that we can assume that it is being filed within the USPTO.] It appears to me (and I'm willing to take more input) that the general consensus is that an IPR-encumbered syslog/tls document would not gain acceptance within the development community. I would like to do 2 things at this time: 1) I will ask Huawei to update their IPR claim to cover draft-ietf-syslog-transport-tls-02.txt (the current disclosure only covers -01.txt) and, if possible, to give us a bit more of a clue as to what the IPR covers. Specifically from RFC 3979, Section 6.4.1: In addition, if the IETF Document includes multiple parts and it is not reasonably apparent which part of such IETF Document is alleged to be Covered by the IPR in question, it is helpful if the discloser identifies the sections of the IETF Document that are alleged to be so Covered. I believe that Hauwei does not need to fully disclose their IPR claim but a clue would be helpful. I think that the section above was written that way so that it could be possible to remove or modify a section so that the document would no longer be covered by a claim. I don't know that this is possible in this case but I'd like to explore that option. 2) I will ask our Advisor to give us some guidance on this. (Sam is cc'd.) We agreed to a tight timeline for our deliverables without considering that we would get hung up on this. A recommendation has been made on the WG list that we proceed with syslog-transport-udp and syslog-protocol while we see what becomes of the IPR claim of syslog-transport-tls. We CAN submit syslog-transport-tls in a timely fashion, as per our Charter, but I fear that it would not be accepted or deployed by the community until the IPR issue is resolved. Moving forward with the other two IDs would keep our momentum going and we could address the issue of the IPR as soon as we can. 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: Framing in syslog messages - RE: [Syslog]Preliminarysyslog-transport-tls document - issue 3
Bazsi, Agreed, let's go for octet-counting. How would that look like? Two octets before every message? That would limit message size to 64k, is that sufficient? (I personally say it is, messages larger than 64k would potentially mean that they cannot be held in memory) there is the good, old size issue resurfacing. I'd say let's not get on that slippery slope again. The compromise so far is - you can use any size as long as the receiver permits it. I'd say we should stick with it. That means we should probably also stick with the ASCII-only Space delimited header. So the transport header would be something like this TLS-HEAD = OCTCOUNT SP OCTCOUNT = 1* DIGIT Two practical samples would be 140 rest of syslog message or 256000 rest of syslog message The later is an intentionally horrible long message. But again, I'd leave this door open. If the receiver thinks 256000 octets is too large, it can read the first 64k and drop the rest. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: Framing in syslog messages - RE: [Syslog] Preliminarysyslog-transport-tls document - issue 3
Baszi, I see the following possible upsides of using some kind of framing: * byte-counted messages, effectively allowing the use of the full character set * application layer acknowledgements, avoid losing messages sitting in the TCP socket buffers without knowing that they were not really sent. * control messages * multiplexed channels The question is which ones do we want to implement and how this correlates with the previous work on BEEP. Honestly, I think if we take that route, we can simply implement RFC 3195. Actually, it offers all this and I do not see any way it could be done with much less effort than already done in RFC 3195. BEEP looks complex, but it is not all that bad once you nail it down. For this discussion thread, I think we are looking at a very simplistic SSL based transport. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: Framing in syslog messages - RE: [Syslog] Preliminarysyslog-transport-tls document - issue 3
My 2 cents... Do the byte counting. Look at the headers of pretty much any successful protocol (TCP, IP, UDP, etc) - they all specify length of payload. Special character sequence is really a hack IMO! After some thinking, I agree with Anton. I, too, think that octet-counting is superior, as it leaves the door open for changes in the upper layer. So I now strongly vote for using this approach. Just to be clear, there was never any intention to allow multiple messages per UDP datagram. So, this discussion probably does not apply to the UDP transport mapping. I agree on this point with Anton. We should not add any additional overhead to the UDP transport. There is few reasoning for multi-chunk messages in a potentially 448-octet constraint message. There may be some valid use cases with ultra-compact messenging, but that should probably done in another transport and/or optionally in a revision once we got some experience with actual implementations. Rainer Thanks, Anton. -Original Message- From: Chris Lonvick (clonvick) Sent: Wednesday, March 15, 2006 5:26 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: Framing in syslog messages - RE: [Syslog] Preliminarysyslog-transport-tls document - issue 3 Hi, This is an issue that we need to discuss. I've had some discussions with various people on this subject who's opinions I trust. They also suggest that we do have 2 options as Rainer states. Let me describe this in a bit more detail: The consensus from all is that syslog-protocol should not explain how to have multiple syslog messages in each packet. That should be done in each of the transport documents so that transport mechanisms can frame the messages. This ensures a good fit if syslog is placed into a new transport that already has a framing mechanism. This is how it has been done in RFC 3195. As Rainer says, we can reserve a character or characters to separate messages. We could use ASCII characters such as CRLF or we could use a UTF8 character. See: http://www.unicode.org/faq/utf_bom.html and http://www.unicode.org/reports/tr14/index.html This would require that we place a very strong message in the Security Considerations section of each transport document that would warn against an inappropriate use of the separator character(s). For example, if CRLF is chosen as the separator, the receiver may get a message with a CRLF in it that does not signify a separation of messages. This will probably go away with time as more poeple adopt to the standard. Alternatively, we could count bytes to show the end of a message. The receiver would count to that point and decide if there is another message after that. Having this option would not require any additional messages in the Security Considerations section as there would be no doubt about the end of a message. I want to open this discussion to the group. If we can agree to some mechanism then we'll get Anton, Fuyou and Yuzhi to put this into their IDs. I will say that the WG is not addressing the transport of binary messages at this time. However, I know that it's a concern of this group and I would hope that the people who think about this take that thought into consideration when they send in their comments. Thanks, Chris On Wed, 15 Mar 2006, Rainer Gerhards wrote: Miao, thanks for the great (and quick) work. I can not review it fully right now, but I have seen one issue that I would like to comment immediately on. More comments follow later. [Issue 3] The problem of CR LF is it can not process binary data well. How to process Syslog signature/certificate message? With the current status of syslog-protocol, you can NOT do octet-stuffing. The reason is that any character is valid inside MSG and this includes the CR LF sequence. So we have two options: 1. change -protocol to disallow CR LF 2. use byte-counting for framing in -tls Option 1 has been discussed in the past and mostly been rejected. However, this is the first time that we have a real standardization use case for excluding it. Currently existing (non-standard) syslog/TCP uses CR LF (or lone LF) as record delimiter. So it might be useful to take that route. Option 2 has the advantage of greater aplicability plus enables the application developer to use more efficient buffering (as the needed buffer space is known in advance). I have no strong opinion which option is better, but I tend a little bit to option 2. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list
RE: [Syslog] Preliminary syslog-transport-tls document - issue 3
Miao, thanks for the great (and quick) work. I can not review it fully right now, but I have seen one issue that I would like to comment immediately on. More comments follow later. [Issue 3] The problem of CR LF is it can not process binary data well. How to process Syslog signature/certificate message? With the current status of syslog-protocol, you can NOT do octet-stuffing. The reason is that any character is valid inside MSG and this includes the CR LF sequence. So we have two options: 1. change -protocol to disallow CR LF 2. use byte-counting for framing in -tls Option 1 has been discussed in the past and mostly been rejected. However, this is the first time that we have a real standardization use case for excluding it. Currently existing (non-standard) syslog/TCP uses CR LF (or lone LF) as record delimiter. So it might be useful to take that route. Option 2 has the advantage of greater aplicability plus enables the application developer to use more efficient buffering (as the needed buffer space is known in advance). I have no strong opinion which option is better, but I tend a little bit to option 2. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] implementing -protocol and -transport-udp
David, I agree on this point. But -transport-udp cross-references -protocol and -protocol must cross-reference -transport-tls (or whatever it will be named), so they must be sumbitted together even though there is no direct relationship between -transport-udp and -transport-tls. Rainer -Original Message- From: David B Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 2:12 PM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: RE: [Syslog] implementing -protocol and -transport-udp Hi, Just a point. -transport-udp and -transport-tls should be independent of each other, since one is based on udp and the other on tcp. I just want to be sure that is understood. -transport-udp and transport-tls should have a comparable interface to the rest of the syslog documents. Do we agree on that point? David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Monday, February 13, 2006 2:46 AM To: [EMAIL PROTECTED] Subject: [Syslog] implementing -protocol and -transport-udp Hi all, it is nice to see us making progress. However, as we need to finish (and start) a secure transport before we can submit -protocol and -transport-udp, I have a question to the implementors here on the list. -transport-udp is basically finished and -protocol just needs a brush up (aka hopefully soon finished). I wonder if some folks would like to implement these drafts, even before they are submitted (aka soon ;)). I see several advantages in doing so: - we get real-world experience about what is practical and what not - this enables us to create a better standard - we can do interop-testing between different implementations, again clarifying how good the text is - we prepare for rapid deployment once the draft has been submitted - we (and our users) can enjoy the benefits of the standardized format earlier - we have implementation reports at hand when the IESG asks about vendor and user acceptance Remember that both drafts are essentially ready for publication - what is missing is just a secure transport, which does not interfere with what we currently have. Of course, implementations could lead to new discussions and eventual changes to the draft. I think is is better to have this now then when it is released. I already did a test implementation in rsyslog. It prooved to be quite easy and quickly doable. If others agreee to implement it too, I would go ahead and also see that we implement it in our commercial packages. I hope that my proposal is a good one and that other implementors would like to participate. Please reply on list if you think this would be a good idea or not. Many thanks, Rainer ___ 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] Threat model requirements discussion
FWIW: I agree with Baszi in all points. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler Sent: Tuesday, January 31, 2006 2:35 PM To: Tom Petch Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Syslog] Threat model requirements discussion On Tue, 2006-01-31 at 11:28 +0100, Tom Petch wrote: So I want to see a simpler solution - eg keyed hash - first and a more complex one which includes encryption as phase two (2007?). And yes, my views are coloured by SNMP which I have worked with for many years, where, as I have said before, users tell me they must have encryption but it usually turns out they have not yet learnt about the concept of differing threats. My points: * syslog is way different than SNMP traps, it really does contain sensitive information (not just link up/down). * adding TLS is very simple from the implementation point of view: adding a new transport layer to the software stack does not really change the software (can be done without changing the software at all via a wrapper like stunnel), message signatures is a big change in _all_ senders * adding TLS is very simple from the protocol specification point of view: define a way to wrap messages to an envelope (e.g. NL termination, or byte counter) and wrap messages into TLS * adding message signatures is difficult both implementation and specification wise, syslog-sign is far from being simple I'd say that the specification and implementation something like syslog-sign is at least 3-5 times as big work as doing the same with a drop-in package like TLS. But I guess this is a yes/no argument so we have to come up with a decision. I would propose an agenda like: 1) syslog-protocol 2) syslog-protocol over TLS 3) message integrity/authenticity checking in syslog-protocol Or maybe even start work on 2) and 3) in parallel. -- Bazsi ___ 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] Re: Threat model and charter
Chris, I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
Hi Rainer, I'm still not seeing too many responses about how TLS is authenticated. I guess you do not see them because most often it is used anonymous... As of my experience, people are concerend about message observation. Authentication is not their prime concern (my previous post detailled why it isn't - hint: Intranet, authentication via sender IP address). Only Baszi has said that full X.509 certificates should be used - similar to how they are used in stunnel. Is this acceptable to the WG? Anyhow, TLS authentication is pretty easy. If you do it as in stunnel (and that's always an option), you do not necessarily need to set up a full PKI. Files with the private keys do well. Distributing them to the senders should not be more hassle than distributing shared secrets. Should the WG also consider using PSKs as proposed in RFC 4279? Having authenticated TLS will address many of the threats described in RFC 3164. Is this how the Working Group wants to proceed? I'd like to hear from more people on this. I recommend -transport-tls with two modes: - unauthenticated TLS - authenticatated TLS both are mandatory to implement but the user can choose which one he needs (that means that nobody is forced to distribute certs or PKI if only message observation shall be mitigated). Rainer Thanks, Chris On Wed, 18 Jan 2006, Rainer Gerhards wrote: Chris, I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: SSH - RE: [Syslog] Re: Threat model and charter
Just for the records, we (Adiscon - WinSyslog, MonitorWare, rsyslog) do not plan to support SSH either. We plan native TLS first in rsyslog and later in the Windows product. I guess we'll try to make it compatible to syslog-ng no matter if this will be an IETF or industry standard. I expect this to be fairly easy (AFIK our products interoperate via the stunnel hack over SSL). Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:40 PM To: Chris Lonvick Cc: Rainer Gerhards; [EMAIL PROTECTED] Subject: Re: SSH - RE: [Syslog] Re: Threat model and charter On Wed, 2006-01-11 at 06:29 -0800, Chris Lonvick wrote: Hi, I forgot to address the use of SSH for authentication. The isms WG is trying to use SSH to provide security for SNMPv3. This can be done by having the devices authenticate by having a username and credential (password, public key, etc.). Again, this sounds to me like it's getting further away from the ease of deployment for syslog than we'd like. However, Rainer mentioned that he thought some people were already using SSH to transport syslog. I need to ask: How many people have implementations that use SSH, and how many are planning this? I for one (syslog-ng) don't plan to add native support to SSH, although SSH can be integrated into syslog-ng by using the program destination, something like this: program(ssh -i /etc/syslog-ng/ssh.key [EMAIL PROTECTED] /usr/bin/logger -f); However I don't see this as a very good solution. On the other hand I'm planning on adding TLS natively (instead of using stunnel style hacks). -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
I'm concerned that your analysis seems to be based on what is easy to implement. Well, I have to admit that in the world of syslog people vote with their feet. If it is not easy to implement (better said: deploy), the majority will not deploy it. Maybe I have a false impression, but I think I am not totally wrong. Security is only as secure as people actually use it. Just think about the nice yellow post it notes below the keyboards where all these strong passwords that nobody can remember are being kept. Is it really a good thing to have a multitude of strong passwords that leads to people resort to easily accessible, totally insecure paper notes? Wouldn't it be better to have fewer and not so totally strong passwords, but ones that are actually used as designed? I know there can be a lot said in this regard - I do not want to go into the specifics here. My point is that security is only as good as it is being accepted by the typical user. Stronger security might actually turn out to be weaker when you look at how it is actually *used*. We also need to do the analysis of what security is actually required by syslog deployments. If the ansers are different, we'll have to deal with that. I thought we are doing this by refering to the sections in RFC 3164 and syslog-protocol-16. Do you think we need to elaborate more on the potential threats? If so, we definitely would need to reconsider that part of the work (also in -protocol, because it should mention at least all transport-independant threats). But e are in a different situation if we decide to do something because we don't know how to do better than if we meet what we believe the security requirements are. I think with TLS and certificates we can address the security threads I mentioned. Making the use of certificates optional for operators is in the spirit of what I said above. I don't see any unnecessary evil in that. After all, even seat belts are somewhat optional. So far, cars don't force their drivers to wear them (all attempts to actually force the driver have been circumvented by the user). Please advise. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
I agree with Balazs suggestion and his reasoning. Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 10:52 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Charter comments from IESG Review On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Hi Sam WG, I understand the reasoning behind requiring a security mechanism. I just want to remind everyone that a major drawback in Vancouver was that we had lost some backwards-compatibility to existing syslog implementations. The weeks after Vancouver we worked hard to find a minimum consensus on how we could provide the needed backwards compatibility. When we mandate a security mechanism, we must be very careful not to invalidate all these attempts. Why? Simply because any transport-layer requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with currently existing syslog implementations. So due to this requirement, we can not create a backwards-compatible spec (not even in the sense that existing receivers can put messages in the right bins). So in my point of view the only option is to use structured-data embedded signatures. As they do not modify the message format AND work over UDP, they allow old receivers to receive messages and put them into the right bins while new receivers can enjoy their benefits. In my point of view, anything further (like required confidentiality) conflicts with the backwards-compatibility approach and thus with the rest of the new charter. So I propose we update the charter to include that item and make sure syslog-sign advances. Syslog-protocol can than require all messages to be signed via syslog-sign. Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Thursday, January 05, 2006 11:12 PM To: [EMAIL PROTECTED] Subject: [Syslog] Charter comments from IESG Review Hi. The IESg reviewed the proposed syslog charter at today's telechat and decided that it requires revision. The main concern seems to be the lack of a mandatory to implement security mechanism. I indicated this might be the case in the Vancouver meeting. so, you definitely need to have some sort of mandatory to implement security mechanism. I'm not quite sure what needs to be said about this in the charter. But the working group will need to: 1) Identify a threat model for syslog 2) Define mechanisms to address these threats. So, questions for the threat model include things like whether confidentiality is important or whether integrity of mesages is sufficient. Depending on the threat model here are some possible solutions: 1) Require some transport like syslog over TLS|DTLS be implemented. 2) Require that all senders implement signatures stored in structured data as an option. I don't think you need to commit to one of these options now. However, you do need to reflect the security issues in the charter. --Sam ___ 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] Charter comments from IESG Review
Tom, If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication They use pre-shared secrets. It's probably best if you look at syslog-sign, which provides the necessary mechanisms for syslog. Please note that it still transmits data in clear-text (which I consider a requirement to remain backwards-compatible). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
-Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 1:08 PM To: Rainer Gerhards Cc: Tom Petch; [EMAIL PROTECTED] Subject: Re: [Syslog] Charter comments from IESG Review Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer Tom, If so, yes, both S/MIME and OpenPGP support this model. However I'll point oun that it is not a requirement that syslog work that way; for example RFC 3195 certainly has connections. I'll look at those, thanks. I agree syslog could be, perhaps should be for meaningful security, but often at present is not, so I wanted to see what security was possible with just one way communication Rainer They use pre-shared secrets. Not typically. They typically use public keys. Sorry, yes, I was totally wrong in my wording. What I intended to say was that the keys are exchanged on a medium different then the current session (e.g. key servers). So this means some other protocol is required to obtain that information (and it is processed outside of the syslog protocol). Thus, I wanted to say, it does not necessarily need to change the simplex nature of syslog (but some initial negotiation is necessary, which I do not think to be a problem). Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
Sam, Rainer Why? Simply Rainer because any transport-layer requirement (DTSL, SSL, SSH, Rainer whatever) would NOT be compatible with currently existing Rainer syslog implementations. So due to this requirement, we can Rainer not create a backwards-compatible spec (not even in the Rainer sense that existing receivers can put messages in the Rainer right bins). Let's be clear about what backward compatibility we're looking for. Do we require that new senders be able to be configured to talk to old receivers? I depens on what you mean with that - if to be configured to talk to old receivers means they must not use -protocol but rfc 3164 instead, this is not what was discussed on this list (-protocol-14 had addressed this already). Or do we require that old receivers be able to put any message from a new sender into the right place? Not over any transport, but the core need behind the recent changes was that -protocol/-transport-udp messages should allow an old sender to put it into the right bin. This implies plain text transmission. In particular what you're seeming to say implies that we cannot define new transports because doing so would be backward incompatible. I don't think that is what we said. If we do define a new transport, presumably both UDP and the secure transport would be mandatory to implement. This looks like I misunderstood your intension. I thought that unsecured UDP should no longer be supported. So what you actually said is that we can go ahead with the unsecured UDP as long as we also mandate a (different) secure transport. If that is the case, I am reliefed, because this is something that can practically be done. And, yes, configuring a sender to use unsecured udp (-transport-udp) for one target and a secured transport for another target is definitely a good option. We just need to be able to interoperate with the unsecured plain text udp syslog world. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Sec 6.1: Truncation
Rainer: I agree - this is better than a convoluted rule. I think we only have any business in defining truncation for relays. For collectors, we have tried to stay away from describing how messages are stored. For relays, I think it would be useful to state that relay can't just drop arbitrary message parts. Your statements about some parts ... are lost may be interpreted that way. Actually, this was what I meant ;) [I saw a number of use cases where it would make sense to strip some known-not-so-relavant SD-IDs to be strippedd], but ... I would recommend that we state that any truncation must happen at the end of the message, which I think is what truncation means to a lot of people anyway. This would prevent an implementation which prefers to throw out STRUCTURED-DATA before the MSG content. A consistent behavior is useful for interop and, in particular, may help in dealing with security issues. ^^^ ... this is more important. I now agree with your point. As a side-note, we had the idea that relay operations may become a separate document, so I would prefer not to dig too deep into relay behaviour. To specify what you recommend, this is not necessary, so this is not really a discussion topic here. Rainer Thanks, Anton. -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 3:21 AM To: Anton Okmianski (aokmians) Subject: RE: [Syslog] Sec 6.1: Truncation Anton, Darren, I agree that the truncation rule is probably not really useful, even confusing. I think it is hard to predict for any potential message if the more interesting content is in STRUCTURED-DATA or in the MSG part. For example, with our current SD-IDs, I'd prefer to trunctate them instead of MSG. Obviously, the case is different for your LINKDOWN sample. I also agree with Darren that truncation probably happens on the transport layer, the application may not even see the full message. My conclusion, however, is slightly different: I recommend now that we remove truncation rules from -protocol. We should just say that truncation might happen and that in this case some parts of the message are lost - what is at the discretion of the receiver. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski (aokmians) Sent: Friday, January 06, 2006 9:48 PM To: [EMAIL PROTECTED] Subject: [Syslog] Sec 6.1: Truncation Rainer and all: I started reading draft #16. Since we are revisiting everything... I am not very comfortable with the current truncation rules. Receivers SHOULD follow this order of preference when it comes to truncation: 1) No truncation 2) Truncation by dropping SD-ELEMENTs 3) If 2) not sufficient, truncate MSG I don't think that this is a good recommendation. I would assume that in many cases people would try to tokenize more important data into structured data and use message text as a secondary user-friendly description. For example, for LINK_DOWN message, I would probably encode link ID in the structured elements as this is something that should be readily available for receivers. The MSGID could be LINK_DOWN and the MSG text may simply be Link down. If you truncate the structured data, it makes it harder. I also think, in general it is useful to put more important data first, which is another reason for putting more valuable data into structured data in a more compact way. Additionally, structured data can be used to provide message length or digest, which can help receiver to determine if message was truncated. Also, I think this statement is very convoluted: Please note that it is possible that the MSG field is truncated without dropping any SD-PARAMS. This is the case if a message with an empty STRUCTURED-DATA field must be truncated. I think I understand what you are driving at, but I don't see it as adding any requirements or clarification. This sentence is not clear although I know what you are trying to say: The limits below are minimum maximum lengths, not maximum length. I propose replacing the entire section 6.1 with this text: Syslog message limits are dictated by the syslog transport mapping in use. Each transport mapping MUST define the minimum required message length support. Any syslog transport mapping MUST support messages of up to and including 480 octets in length. Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length. All receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers MAY receive messages larger
RE: [Syslog] #7, field order
Tom, loool - thanks, yes exactly this is it. Believe it or not, I've been banging my head for hours hours and I still didn't get it. Silly me ;) Thanks for the help. Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 10:27 AM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: Re: [Syslog] #7, field order Not sure I have grasped the problem yet but the cases you cite would appear to be covered by rules of the form, using pseudo-English as a shortcut, FIELD = ONECHAR / MORECHAR ONECHAR = anyprintable character except hyphen-minus MORECHAR = anyprintable character 1*any printable character which prohibits - but allows -- i -id- etc (but not:-) Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 21, 2005 6:16 PM Subject: RE: [Syslog] #7, field order David, Darren, even though no responses indicated we actually need to fix this, I wanted to at least try an alternate ABNF. However, I did not find a suitable one. Probably I am not smart enough to find it, so I am asking if somebody else could come up with one (and if not, that would be a definite answer to the original question). Darren suggested something along the lines of field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 missing ::= - However, that doesn't seem to catch all cases. So I tried to craft some ABNF that allows all cases, which includes the strings below (each on a separate line) -- -id- -id id- i-d i but disallows - However, I did not succeed in this effort. Either I do not know enough about ABNF (may well be) or it is actually impossible to describe such a beast in just the grammar. From the implementors point of view, I think it is pretty easy to parse everything and then compare it to a sole -. But that's not the point of this question. The question is if there is a way to make the *parser* do the differentiation. I'd appreciate any comments on this. Rainer -Original Message- From: David B Harrington [mailto:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 6:50 PM To: Rainer Gerhards; 'Darren Reed' Subject: RE: [Syslog] #7, field order Hi, Having a public feud won't help us achieve our goals. I suspect I fall into the same category as most of the working group: I'm not convinced there is a serious problem. I'm not sure which is the best technical solution. I'm not convinced it matters which way we do it. I would be more convinced if multiple implementors said it's a problem. As an experienced WG chair, I am not convinced there is consensus to solve the problem. As an experienced WG chair, I've had one person claim there is a problem, and had the WG advance the spec without solving the problem, and had the problem come back to bite us in the backside. Here's what I suggest as a way forward on this issue. Will the implementors listening in this WG tell us if they think there is a serious problem with the - and space and the ABNF, et.al., and tell us how to solve it in a manner that you would find acceptable? If it's a problem let's get multiple voices working on a solution. If it's not a problem, let's reach consensus it is not a problem and move on. Thanks, David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Thursday, December 15, 2005 4:39 AM To: Darren Reed Cc: [EMAIL PROTECTED] Subject: [Syslog] #7, field order Darren, that's why I take your comment not seriously: data for that field. If you don't understand the difference here, I think the fields need to be defined something like this: field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255 missing ::= - And as someone else pointed out to me, PRINTUSASCII includes the space charactr (0x20), which is used as the field delimeter. This needs to be fixed too. If you would look at the ABNF, you would find PRINTUSASCII= %d33-126 This is the problem with your comments: you claim things while at the same time you show that you are uninformed (at best). I believe in peer review, not in peer rumor... I assign peers some credibility and yours has gotten quite low over time. It's my personal judgement, but again I am stating everything honestly on-list so that others thinking your way can add their comments, which would obviously increase their weight. I guess that's common sense and not just my party ;) [but I have to admit that I personally do not care about what you think about me and my party]. As another technical comment, - for me is proper field content. It is just a special value which
