[Syslog] Documenting the configuration of syslog
Hi WG, Things are changing in the IETF around documenting the management and operations of protocols. The OPS Area WG has been documenting a change of approach, in which SNMP and MIBs are not the only way to configure, manage and operate a protocol, and existing practices are taken into greater consideration when choosing the right tool for a task. We'd like to open that discussion to the WG to get some opinions on this. If we can get a sense of direction on this from the WG, then we'll discuss this with our Advisor (Sam) and our ADs. Documenting the current operational practices for configuring syslog (i.e. syslog.conf) might be much more useful to the operator community than developing a MIB module to do syslog configuration. Is standardizing aspects of the common syslog.conf configuration file the best way to show how to configure a device to send syslog messages securely across the wire? Another approach would be to define some standard Netconf data models for configuring secure syslog, but that is likely to get into serious scope discussions that would bog down such an approach. Our chartered focus is to resolve security issues in logging, so we need to stay focused on defining management to support the work we have done here. It is not in scope to define a comnplete syslog.conf file format, nor to standardize aspects of the file not related to configuring secure logging. Common syslog.conf files already address udp transport but we would need to define how to also utilize tls and RFC3195 transports in this work, and possibly how to configure syslog.conf to support syslog signing. The OpSec WG is discussing whether to document best current practices for syslog operations. If they do so, we may need to coordinate with the OpSec WG about configuring security for syslog. If syslog.conf is covered in the standards of other standards development organizations, such as POSIX, we also may need to liaison with those SDOs to get support for our modifications to syslog.conf. If we do propose standard content for a configuration file for syslog, we will still need to make the WG designs manageable for purposes of monitoring. A MIB module is the current IETF best practice for providing information for fault and performance monitoring and for notifications. Please respond to this and let us know if you think that documenting some standardized content for syslog.conf is going to be a better way to clarify the configuration of syslog rather than writing a MIB module that includes configuration functionality. Thanks, Chris David ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Documenting the configuration of syslog
Hi Anton, Perhaps I wasn't so verbose in my original posting. Documenting the SNMP MIBs will give us counters and a way to configure syslog via SNMP. We've had many discussions of what we want to count, and how it _should_ add up. We've also had discussions on how to tell a syslog device how it should enable the transmission of messages and what Facilities and Severities it should send to where. From those discussions, however, David and I are not sure that anyone will ever use those counters, or will ever use SNMP to configure syslog. If that's the case, then we don't feel that we should go through the effort to produce such a document. On the other hand, we know that many people edit syslog.conf. Perhaps we should document how to enable the sending of syslog messages as it has historically been done, and forget about counters if no one here objects. If we go this route then we do not see the need in the syslog WG to fully document how to filter received messages nor how to select messages for transmission. We think that we can provide the Operator community a good service by describing how lpr.* messages can be transmitted to [EMAIL PROTECTED] via udp, and how to transmit kern.* messages to a different machine via tls. The interoperability we hope to achieve by documenting syslog.conf (in it's most generic form) will be to demonstrate the configuration aspects that an operator will have to address to make it work. For simple udp transport, it is to just assign an address. For tls, someone will need to think through the aspects of how to designate the certificate that will be presented by the server, and what policy decisions will need to be made on the sender. Similar thoughts will need to be done for 3195 configurations. I agree that documenting all of the potential features of the syslog appliation is out of scope for this WG. We're merely asking if the WG feels that a simpler document on how to configure and use syslog would be more beneficial than documenting a MIB. Thanks, Chris On Wed, 16 Jan 2008, Anton Okmyanskiy (aokmians) wrote: Does defining configuration concepts require that you define the functional aspects of syslog application? I can see many different uses of syslog, each requiring different configuration. It all depends on the context it is used in. It can be stand-along, it can be embedded, it can be part of a logging library. It can be a forwarder, a receiver or both. A receiver can write to file or database. It can be configured to ignore some messages based message names or whatever patterns. Forwarder can buffer things in various ways, throttle them, etc. A receiver can do de-duplication, correlation, etc. There is not end of features an syslog application may have. The UNIX syslog daemon is just one example application using syslog protocol. The original one is pretty trivial one and mostly geared towards local logging by OS sub-systems. Even Solaris and Linux syslog daemons have slightly different features. Another question is what kind of interop do we accomplish with standard configuration of syslog? Is it important? My gut feel is that defining standard configuration for syslog application is a dead-end because it requires us to define the specific application. IMO, we should let the specific application designers do that. Regards, Anton. -Original Message- From: Chris Lonvick (clonvick) Sent: Wednesday, January 16, 2008 5:32 AM To: [EMAIL PROTECTED] Subject: [Syslog] Documenting the configuration of syslog Hi WG, Things are changing in the IETF around documenting the management and operations of protocols. The OPS Area WG has been documenting a change of approach, in which SNMP and MIBs are not the only way to configure, manage and operate a protocol, and existing practices are taken into greater consideration when choosing the right tool for a task. We'd like to open that discussion to the WG to get some opinions on this. If we can get a sense of direction on this from the WG, then we'll discuss this with our Advisor (Sam) and our ADs. Documenting the current operational practices for configuring syslog (i.e. syslog.conf) might be much more useful to the operator community than developing a MIB module to do syslog configuration. Is standardizing aspects of the common syslog.conf configuration file the best way to show how to configure a device to send syslog messages securely across the wire? Another approach would be to define some standard Netconf data models for configuring secure syslog, but that is likely to get into serious scope discussions that would bog down such an approach. Our chartered focus is to resolve security issues in logging, so we need to stay focused on defining management to support the work we have done here. It is not in scope to define a comnplete syslog.conf file format, nor to standardize aspects of the file not related to configuring secure logging. Common syslog.conf
RE: [Syslog] syslog/tls
Hi, It made it into the repository today. Please review and comment. Thanks, Chris On Mon, 19 Nov 2007, Rainer Gerhards wrote: David, it may be just my problem, but... I have not seen any updated doc. Did I miss something? Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Sunday, November 18, 2007 11:20 PM To: [EMAIL PROTECTED] Subject: [Syslog] syslog/tls Hi, syslog/tls has been updated to match the requests from IESG review. If you have strong objection to the updated text, please raise your objections asap. David Harrington [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] Authentication, certificates, trust anchor, cipher suite and deployability for syslog/tls
Hi Folks, I have not seen any further discussion on this but we still have some open issues. I like the idea of describing the cases for the clients and servers to have (or not have) certificates. For high deployability, I believe that the client would not need one at all. At the other extreme, for high security, the clients and servers would need common trust points and certificates. Please pitch in on this discussion. Thanks, Chris On Wed, 3 Oct 2007, Miao Fuyou wrote: Hi Anton, Thanks for your feedback! Environment where active attack is concern: The server is configured with certificate, but the client is not to be required to be configured with a certificate. The client can generate a selt-signed certificate by itself. Why do you need a self-signed certificate here? What purpose does it serve? The client MAY use a self-signed certificate. You are not proposing using it for client authentication here, are you? Not exactly. This is to explore various possible options with regard to certificate, perhaps it is not necessary to appear in the specification. What is that? Let's be more specific if you intend to put this in the doc (same goes for names of these 3 scenarios). I think this configuration does two things: encryption and server authentication. Active attack involves an attempts to change information by contrast with passive attack. To be more specific, it is man-in-the-middle attack is this case. but is vulnerable to client spoof. Security insensitive environment: Both the client and server are not required to be configured with certificate and trust anchor. They generate self-signed certificates. Again, why do you need client self-signed certificate here? It is very easy for deployment because almost there is no configuration required. Note this configuration is vulnerable to active attack. More specifically, this configuration provides only encryption, but no authentication. Which configuration should be mandatory? I seems we need not a mandatory configuration from the PoV of implementation, right? However, we do need to mandate the implementation (both client and server) to support certificate configuration, trust anchor configuration, and self-signed certificate. Let's separate what is required for implementation, and what is required for deployment. I think server MUST implement be deployed with a server-based certificates for this transport. Whether it is self-signed or CA-signed can probably be left to a deployment choice. If it is self-signed, then effectively no server authentication is done, just encryption. The other part is client authentication. I think the server MUST support authenticating clients with certificates and client authentication is OPTIONAL for deployment. The minimum authentication that server MUST support is validating the client certificate against trusted CA. OK. A more secure server MAY also want to implement a mechanism which prevents an authenticated client from masquerading as something else in the messages that it emits. For example, 1mln certs may be signed by the same CA, but we don't want one client with one such cert to be able to masquerade as any of the 1mln other clients. To accomplish this, the server need to take client identity from CN field of the certificate and either validate it against some field in syslog message, or at least plug the CN value into the syslog message structured data, so that admin can do whatever validation he/she desires when needed. I think it is good to describe this additional client authentication consideration, but leave it as OPTIONAL. I think we discussed standardizing a unique CN field value before and it was not fruitful. Standard syslog structured field name for CN value would be a good idea. Good idea, but I tend to not mix the content with its tranport. BTW, TLS transport is hop-by-hop protocol rather than an end-to-end protocol, so it will have difficulties to decide the content when the client is just a relay. We will need to specify a cipher suite (probably RSA-AES-CBC) for inter-operatability, We need to specify at least 2 because one of them may become vulnerable after standard is released and software is deployed. The client MUST advertise support of cipher suite X Y. Server will select the appropriate one based on its configuration for the TLS session. Server should not be forced to select one of those two. I don't think there is any server requirement here. As for specific cipher suites, it will probably be a religious debate. Maybe IETF has a policy on this? I have seen one other standard require these two: * RSA_WITH_3DES_EDE_CBC_SHA * RSA_WITH_RC4_128_SHA RC4 is for stream application, does it apply to Syslog/TLS? RFC4346 mandates TLS_RSA_WITH_3DES_EDE_CBC_SHA, however, I think 3DES is a interim algorithm. Actually TLS 1.2 draft mandates TLS_RSA_WITH_AES_128_CBC_SHA. My only concern would be that at least one of them (or
[Syslog] Facilities - normative or informative label
Hi Folks, This is adding to the note that David sent out about syslog-tc-mib-02 and a discussion we've had about the Facilities. David and I have reviewed the mailing list discussion and have concluded that the labels are normative, but irrelevant. For interoperability and backwards compatibility reasons, the values and labels are normative, so the mapping from a label configured by operators in syslog.conf or equivalent consistently maps to the same Facility number regardless of implementation, but the label itself is often semantically meaningless, because there are not enough numbers to cover all possible facilities, and the enumeration (label and value) that is used by an actual facility is, and has historically been, implementation-dependent. For example, the foobar application might log messages as having come from local7, even though there is no local process on the device, and the operator can configure syslog.conf to have local7.critical messages be relayed, even though there might be multiple facilities using Facility local7. This is typical current practice, and originators, relays and collectors know how to handle this situation. For improved accuracy, the foobar application can also include an APPNAME SDE in the message identifying itself as the foobar application. Also, I believe it is the intent of the WG that _all_ processes have the ability to use the syslog transport to send their messages to a device that might care. My concern is that we'll never have enough Facilities to distincly identify all possible processes that might want to send messages. I think that we had a discussion a long time ago about trying to associate a number with each process, with enough expansion to cover the future. It didn't work out then and it won't work now. Another way to say what I'm thinking is that that some policy may be enacted at my company to say that my foo.log or my virusscan.log (as examples) be forwarded from my machine to some central repository. Neither of these things are going to be able to use a defined Facility but they could both use local7 simultaneously. Some process at the receiver would have to separate them based upon APPNAME. ___ 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-8 security
Hi Sam, I've heard no objection from the WG on your proposed wording. Please go with that. Thanks, Chris On Mon, 10 Sep 2007, Sam Hartman wrote: 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
Re: [Syslog] Change between syslog-protocol 21 and 23 breaks UTF-8 security
Hi Sam, I'm going to wait a day or so for any input from the WG. However, the proposed text seems to be acceptable. Do you want a new ID, or is this something that we can change in AUTH24? Thanks, Chris On Fri, 7 Sep 2007, Sam Hartman wrote: Hi, folks. I think the WG made a mistake trying to address Chris Newman's comment about Unicode TR36 and made the situation worse. My understanding of what the WG was trying to do is to require that if a BOM is present in a string, then the implementation can enforce strict checks because it knows the message is Unicode and UTF-8. Without the BOM, there's not a lot you can do. The goal here is to have consistent and secure internationalization between two new implementations--that is a sender that includes the BOM and a receiver that understands it. So, basically the BOM is a signal that Hi, there; I'm new and you can trust my i18n to be reasonably well thought through. The following change seems to break this. - If a syslog application is processing a MSG starting with a BOM, then - it MUST be interpreted as being encoded in UTF-8 for the reasons - outlined in UNICODE TR36 [UNICODE-TR36], section 3.1. If a syslog - application does not encode MSG in UTF-8, the string MUST NOT start - with the Unicode BOM. Guidance about this is given in Appendix A.8. + If a syslog application is processing a MSG starting with a BOM, if + it contains UTF-8 that is not shortest form it MUST NOT be + interpreted as being encoded in UTF-8 for the reasons outlined in + [UNICODE-TR36], section 3.1. Guidance about this is given in + Appendix A.8. In particular if you get text from a new implementation that is not shortest-form, it is an error. You want to throw it away , or do something else to indicate you have a security problem, not just treat it as another encoding. I propose the following text but would be open to alternatives: If a syslog application is processing a MSG starting with a BOM, if it contains UTF-8 that is not shortest form it MUST be discarded for the reasons outlined in [UNICODE-TR36], section 3.1. Guidance about this is given in Appendix A.8. ___ 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] Discuss - UDP Checksum
Hi, I don't think that addresses the IESG concerns as well as Juergen's proposal. I'd like to wrap this up. I don't think that there's any disagreement that we need something like this. Would anyone with any other thoughts please send them in. David and I will determine consensus tomorrow. :-) Thanks, Chris On Tue, 10 Jul 2007, Anton Okmyanskiy (aokmians) wrote: I agree with Juergen and Rainer that we could use less specification here since it is a different layer. How about we replace both paragraphs with this: Syslog senders are RECOMMENDED to use UDP checksums when sending messages over IPv4. Proper UDP checksum insertion and verification is already required by IPv6 RFC 1883. Let's be silent on what the receiver has to do since it may not have any control. I think if we put something like Syslog receivers MAY accept syslog message with invalid or zero checksums, it would directly contradict IPv6 RFC, which says: IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. Anton. -Original Message- From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 4:16 PM To: Chris Lonvick (clonvick) Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Discuss - UDP Checksum On Thu, Jul 05, 2007 at 02:14:06PM -0700, Chris Lonvick wrote: How about the following: syslog senders MUST NOT disable UDP checksums. syslog senders SHOULD use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. The last sentence is a bit like requiring that the IPv6 implementation your code happens to run on MUST be correct (and I have no clue how to turn this requirement into syslog code). syslog receivers should be lenient in what they receive. IPv4 receivers SHOULD check the UDP checksums. They SHOULD accept a syslog message with a zero checksum. They MAY discard messages with invalid checksums, or they MAY accept them and attempt to process them. IPv6 receivers MUST check the UDP checksums and MUST discard UDP packets containing a zero checksum. I am not sure the MAY discard or MAY accept sentence is needed. My proposal would be: syslog senders MUST NOT disable UDP checksums. IPv4 syslog senders SHOULD use UDP checksums when sending messages. Note that RFC 2460 [RFC2460] mandates the use of UDP checksums when sending UDP datagrams over IPv6. syslog receivers MUST NOT disable UDP checksum checks. IPv4 syslog receivers SHOULD check UDP checksums and they SHOULD accept a syslog message with a zero checksum. Note that RFC 2460 [RFC2460] mandates the use of checksums for UDP over IPv6. By simply refering to the IPv6 requirement for UDP checksums, we avoid making this also a syslog requirement. I think we should not use MUST language for something that can only be implemented correctly below the syslog software layer. [Enough hair splitting for today. ;-] /js -- 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
[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 situation implies that one starts discarding syslog messages and starts with the least important ones. So I would like to have a paragraph on this. I also included UDP in this in the case that you actually have reserved or determined that syslog is allowed to use a particular amount of bandwidth, but not more. In this case it could be possible that one implements a rate limiter and run into exactly the same issue as for TCP. Please do understand that if syslog was designed from scratch today it wouldn't get awy without a congestion control that guarantees that it isn't missbehaving in any situation. But being an old protocol we are accepting less than that. However, we do require it to contain the limitations and assumptions that it can be safely operated with. Using it as it currently is used is not an issue because the networks it is used in has many magnitudes more bandwidth that syslog generates. However, what would happen if some one starts using syslog in low-powered, low-bitrate sensor network for carrying some information. In that situation syslog becomes a potential threat to the stability of the network as it doesn't react at all to congestion if run over UDP. Network failures are also sitation that are problematic to ensure that the inteded resources are available. Thus we do like to protect the utility of what resources do exist. So the repeat: Please seriously consider adding a paragraph about how one can thinn a queue of syslog messages in the base protocol. This as I think it potentially applies to any transport. Also consider when updating the UDP draft and adds what has been discussed with Lars, to add a single sentece with a reference the above paragraph as a method to keep the traffic within the allowed resources. Regards Magnus David Harrington skrev: Hi Magnus, Syslog is a fire-and-forget protocol. We have no feedback mechanism that permits us to recognize congestion and rate limit traffic based on that feedback. Syslog is not a brand new protocol; it is widely used in the industry, and other aspects of standardization has been handled through POSIX and BSD standardization. The industry has expressed no interest in making this a two-way protocol. This protocol is widely used by operators, amd I have seen no demand from operators to make this a two-way protocol, or any demand to resolve congestion control for syslog, because congestion caused by syslog apparently is not a problem in the real world. We had discussion of rate-limiting during the IETF Last Call. We actually had suggestions for ways to rate-limit syslog in the earlier document, but the IETF community rejected our having that text in the document because syslog is a fire-and-forget protocol, so there is no reliable mechanism for detecting congestion. The IETF commmunity did not ask us to make syslog two-way, so we could add rate limiting to the protocol; they asked us to keep syslog working as is, and remove the unreliable recommendations to rate limit. You are placing a whole new requirement, that no implementers or operators are asking for, on a protocol that is already widely implemented and deployed. Where is the customer demand for this? I am concerned you might drive the syslog community to not work within the IETF, where they came to develop a standard message format and a secure transport, not to change the basic nature of the protocol. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Magnus Westerlund IETF Transport Area Director TSVWG Chair
[Syslog] Discuss - Congestion Control
Discuss - Congestion Control Magnus: But what I think is needed here is some clear and normative requirement on how to avoid and limit congestion. First of all I would like to see a restriction on the applicability of this transport to within a controlled environment unless the rate is capped to a level that is TCP friendly or the full path is provisioned to handle the traffic. There should also be a discussion on how one rate limits SYSLOG traffic. Magnus: If any higher rates of packets are to be sent over best effort networks then a feedback mechanism is needed. That would probably need to include forward path UDP packetization layer with sequence number to enable loss detection. Complemented with feedback traffic to enable rate control of outgoing traffic. That could also resolve the PMTUD issue. Lars: draft-ietf-syslog-protocol-21, Section 8.5., paragraph 2: It may be desirable to use a transport with guaranteed delivery to mitigate congestion. Reliable delivery and congestion control are orthogonal features. A reliable transport will not necessarily have congestion control, and vice versa. Lars: draft-ietf-syslog-protocol-21, Section 8.5., paragraph 3: It may also be desirable to include rate-limiting features in syslog originators and relays. This can reduce potential congestion problems when message bursts happen. This is too weak a statement on congestion control. See DISCUSS above. Lars: Given the issues that the UDP transport has with congestion control, security and fragmentation, I'd like the document to recommend the TLS-based transport over the UDP-based one for general use, i.e., when the network is not specifically provisioned for this type of traffic. Prposed Resolution: + Place text in syslog-protocol, syslog-transport-tls, and syslog-transport-udp to state that - udp transport is to be used only where the network is specifically provisioned for this type of traffic, - tls is to be used in all cases where congestion issues may be a concern. + Remove the text in syslog-protocol which states that reliable delivery will mitigate congestion. Response from Lars: I'd like to see the actual text changes, but this proposal exactly captures what I'd like to see happen. Response from Magnus: This mostly addresses my concerns. I still think there is one major issue around this with congestion control. And that is some description on how to rate-limit your traffic. Either in UDP to some pre-configured threshold and in the case of TLS over TCP the rate actually available. There can occur situations where the amount of generated data will be larger than what can be transfered. How does one resolve this? I think it probably needs to be more text in syslog-protocol spec about this. How to use scope and prio to determine which messages to throw away or queue up (within limits). ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Discuss - UDP Length
Discuss - UDP Length Lars: draft-ietf-syslog-transport-udp-09, Section 65535, paragraph 0: This transport mapping supports transmission of syslog messages up to 65535 octets in size. This limit stems from the maximum supported UDP payload of 65535 octets specified in the RFC 768 [1]. DISCUSS: The RFC768 length field includes the UDP header, so the permitted payload size is 65535 minus the UDP header (and for IPv4, minus the IP header, because IPv4 has a 16-bit length field that also includes the header length.) Proposed Resolution: Change the paragraph to This transport mapping supports transmission of syslog messages up to 65535 octets minus the UDP header length. This limit stems from the maximum supported UDP size of 65535 octets specified in the RFC 768 [1]. For IPv4, the maximum payload size is 65535 octets minus the UDP header and minus the IP header because IPv4 has a 16-bit length field that also includes the header length. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] IESG Discusses and Comments
Hi Folks, David and I have been trying to address the open DISCUSSes on -syslog-protocol and -syslog-transport-udp. https://datatracker.ietf.org/idtracker/ballot/1800/ As an aside: Sam has reviewed -syslog-transport-tls and has asked for some modifications. Miao and Yuzhi are working on those and we expect to get that back to the WG for review soon. Until then, we're pushing forward with -protocol and -udp. I've identified 4 Discuss topics: - Source Address - UDP Length - UDP Checksum - Congestion Control For the first three I believe we have some resolution. The WG needs to verify this. There still seems to be an open issue with the last one. When I send these out, please comment. There are also many Comments from the IESG. Some have resulted in some moderate changes, mostly editorial, in the documents. Others I havn't addressed as those are not critical to progressing these documents. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Discuss - Source Address
Discuss - Source Address Lars: draft-ietf-syslog-protocol-21, Section 5., paragraph 2: If a syslog application is running on a machine that has both statically and dynamically assigned addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the syslog application MAY use the IP address of the interface that is used to send the message. DISCUSS: So if a machine has only a dynamic address, it should instead use 127.0.0.1 in syslog messages, because that's statically assigned? That doesn't seem to make sense. Also, in practice, it will be difficult for the syslog sender to determine which addresses are statically or dynamically assigned (think MobileIP or even HIP). Proposed Resolution: The author and the chairs recommend removing this paragraph. Any objection this this? ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Discuss - UDP Checksum
Discuss - UDP Checksum === Magnus: Discuss [2007-06-19]: UDP transport: Section 3.6: It is RECOMMENDED that syslog senders use valid UDP checksums when sending messages over IPv4 and IPv6. It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Why isn't these MUST? For IPv6 it is an MUST and for IPv4 does there exist a single reason not to use the UDP checksum? === Lars: draft-ietf-syslog-transport-udp-09, Section 3.6., paragraph 2: It is RECOMMENDED that syslog senders use valid UDP checksums when sending messages over IPv4 and IPv6. Agree with Tim's DISCUSS - this language weakens the MUST for IPv6. === Tim: Discuss [2007-06-19]: In syslog-transport-udp-09, Section 3.6 (UDP Checksums): The second and third paragraphs could be read as relaxing the requirements (specified in RFC 2460) for IPv6 nodes to generate and verify UDP checksums. It would be clearer if the text described the recommendations for IPv4 independently, and then noted the requirements inherited from RFC 2460 with respect to IPv6. === Discussion w/ Magnus: If I understand this correctly the issue that the first paragraph tries to address is the usage of the UDP checksum, rather than people setting checksums not matching the content of the packet. Because of that I would like to replace valid with the and remove the plural on checksums. By this response I assume that you had no motivation why one shouldn't use the checksum. If that is true, I would recommend staying at MUST strength. In fact I would probably prefer to have the RECOMMENDED to be a MUST also. Unless you have a reason why one wouldn't checksum the UDP syslog packets I would strongly recommend that it is turned on. Our motivation was to not get too far into the way that UDP is known to work. If the proper way to write the document is to say that UDP MUST be checked then we'll gladly do that. Well, UDP for IPv4 does have this option of turning of the checksum. However, I am a strong believer that in most cases it is not the right thing to do. In the syslog case, bit-errors in the text message part may be fine. However, you don't want to have errors in the priority field. Thus throwing away thus packet is probably better than to have them end up in the wrong queue. As I see it moving form RECOMMENDED to MUST will probably not make much difference. You anyway need to write syslog receivers that are handling malformed messages. But it does allow a sender to not use the checksum if they want to. And if the WG is fine with that, having understood the potential issues with that then I am fine. I simply want to ensure that you are aware of the implications of what you write. Proposed resolution (Anton) Ok. If syslog receiver MUST check checksums, we need to also say what it must do in two cases: (a) checksum is not there (value 0) and (b) checksum is wrong. We used to recommend discard only for case B (when it is present and wrong) like this: It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. I suggest we say something stronger in line with a MUST: syslog senders MUST use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers MUST check the checksums and MUST discard messages with missing or incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Agreed? ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Discuss - UDP Checksum
Hi Juergen, Good question. ..and not something that we'll be able to answer in our WG. I'll bring it up in the [EMAIL PROTECTED] list. Thanks, Chris On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote: On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote: We used to recommend discard only for case B (when it is present and wrong) like this: It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. I suggest we say something stronger in line with a MUST: syslog senders MUST use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers MUST check the checksums and MUST discard messages with missing or incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Stupid question: Why is UDP checksumming discussed at all in the SYSLOG UDP transport mapping? People implementing syslog hardly have control over the UDP layer (and for sure not exclusively) and so if at all it only makes sense to me to have operational guidelines that UDP checksums are a good idea - but then again this would not be very much SYSLOG specific - so why discuss this at all in this document? Do we from now on want to have every UDP transport document state that UDP checksums are a good idea? /js -- 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
Re: [Syslog] Discuss - UDP Checksum
Hi, On the other hand... ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-udp-guidelines-01.txt UDP Usage Guidelines for Application Designers (Lars Eggert is co-author). Section 3.4 is Checksum Guidelines. It appears that there is enough question about this that specific guidance should be given in RFCs. Which brings us back to our original question. Is the proposed language below what the WG wants? A quick (and not thorough) check of RFCs which have UDP in their titles shows that RFC 3948, UDP Encapsulation of IPsec ESP Packets , pub. Jan 2005, does have specific guidance on the UDP checksum. To wit: === The UDP header is a standard [RFC0768] header, where o the Source Port and Destination Port MUST be the same as that used by IKE traffic, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value. === I'd like to hear from people who have current syslog/udp code. What works for you? Thanks, Chris On Thu, 5 Jul 2007, Chris Lonvick wrote: Hi Juergen, Good question. ..and not something that we'll be able to answer in our WG. I'll bring it up in the [EMAIL PROTECTED] list. Thanks, Chris On Thu, 5 Jul 2007, Juergen Schoenwaelder wrote: On Thu, Jul 05, 2007 at 07:56:39AM -0700, Chris Lonvick wrote: We used to recommend discard only for case B (when it is present and wrong) like this: It is RECOMMENDED that syslog receivers check the checksums whenever they are present (i.e. the UDP header checksum field value is not 0) and discard messages with incorrect checksums. I suggest we say something stronger in line with a MUST: syslog senders MUST use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers MUST check the checksums and MUST discard messages with missing or incorrect checksums. Note that this is typically accomplished by the UDP layer implementation, and some UDP implementations allow for checksum validation to be enabled or disabled. Stupid question: Why is UDP checksumming discussed at all in the SYSLOG UDP transport mapping? People implementing syslog hardly have control over the UDP layer (and for sure not exclusively) and so if at all it only makes sense to me to have operational guidelines that UDP checksums are a good idea - but then again this would not be very much SYSLOG specific - so why discuss this at all in this document? Do we from now on want to have every UDP transport document state that UDP checksums are a good idea? /js -- 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] Discuss - UDP Checksum
Hi, How about the following: syslog senders MUST NOT disable UDP checksums. syslog senders SHOULD use UDP checksums when sending messages over IPv4. syslog senders MUST use UDP checksums when sending messages over IPv6. syslog receivers should be lenient in what they receive. IPv4 receivers SHOULD check the UDP checksums. They SHOULD accept a syslog message with a zero checksum. They MAY discard messages with invalid checksums, or they MAY accept them and attempt to process them. IPv6 receivers MUST check the UDP checksums and MUST discard UDP packets containing a zero checksum. As a point to this, does anyone actually control the UDP subprocess so that their syslogd will receive corrupt syslog messages? That third sentence of the second paragraph could use some scrutiny. Thanks, Chris On Thu, 5 Jul 2007, Rainer Gerhards wrote: [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
[Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments (fwd)
Hi Folks, This note from Sam to [EMAIL PROTECTED] for those of you who don't subscribe. Thanks, Chris -- Forwarded message -- Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT) From: Sam Hartman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments I'd like to draw the attention of the community to section 3 of draft-ietf-syslog-protocol-21.txt. This text contains text and a clarified model of the various layers in the syslog architecture and new terminology for the parties. I believe this is responsive to the ietf last call comments and I believe the changes have been discussed sufficiently in the WG. I am not asking for a new last call but I do want to make people aware of the text. If people believe a new last call is necessary please let me know now. Currently the document is scheduled on the Thursday, June 21 telechat. ___ 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-tc-mib Facilities
Hi Folks, 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. We've had a lot of discussion during the life of this WG about the Facilities. The WG chose to keep the old Facilities and add more information in each syslog message through the APP-NAME field in the header. Even more information can be added through the SDE of software in the origin SD-ID. (The APP-NAME is REQUIRED but may be nill, whereas the software SDE is OPTIONAL.) This information should be used to clarify the origin of the content of the message. Glenn: Please insert something similar to this in the Introduction part of -syslog-tc-mib. The Facilities used in the syslog protocol have been useful in qualifying the originator of the content of the messages but in some cases they are not specific enough to explicitly identify the source. Implementations of the syslog protocol that contain Structured Data Elements (SDEs) should use these SDEs to clarify the entity that originated the content of the message. (Efforts at wordsmithing this will be appreciated. :-) Also, David is going to find a MIB Doctor to review the next version of -syslog-tc-mib. If that person finds the document to be clean then we will have a short WG Last Call, and then we will submit it to the IESG. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] New -protocol document - your comments needed by 25 June
Hi Folks, I'm going to ask that people review the new -protocol document. http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-21.txt I'd like to get that back to Sam by the 25th. I'm not sure that this will need another IETF Last Call but I'll discuss that with Sam. I want to be clear, the comments I'm looking for are those about the changes made to the document from the last IETF Last Call. The vast majority of the normative sections of the document have been accepted by the WG and by the IETF. We will not be making any changes to those sections. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20
Hi Tom, I appreciate the thoughts. I see consensus in the WG on the layering diagram. I've asked Rainer to update -protocol with that diagram and definitions. Let's get that out the door at this time. I see that we are unclear on what we should be counting and the benefit of counting it. Glenn has separated the mib into textual conventions and the counters. The TC is now here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt Would everyone please review this? I would like for us to establish this as our base and then we can have discussions on counting messages. Thanks, Chris On Fri, 1 Jun 2007, tom.petch wrote: Chris I am fine with the layer diagram given below but I am less clear about the consequences for the MIB. Currently, there is a table with an arbitrary integer index which contains application name, application control file name, receive address and statistics. I have never been too clear on what an entry in this table represents, as I have queried before. The details below suggest that messages sent and received at the transport level become scalars (digression: need to be clear what a message is when this is TLS over TCP) with a table with an entry per relay destination (per application?). Doubt one: we currently do not have any destination information in the table, only a receive address to bind to; will this be added? Doubt two; should we be - we should be! - providing a similar table for originators since they too can send to multiple destinations. Doubt three; should we have a table for different origins, else balancing counters will be difficult? If a collector receives 30 messages when the various relay and originator not relayed counters add up to 25, how do you know which stream has gone missing? or do you parse the message and expect there to be helpful data in the SDE? This is all getting complicated and I am unclear about the benefits of going down this road. Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: tom.petch [EMAIL PROTECTED] Cc: David Harrington [EMAIL PROTECTED]; 'Sam Hartman' [EMAIL PROTECTED]; syslog [EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 7:22 PM Subject: Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20 Hi All, What I'm seeing is that our effort to add granularity for mib accounting has made the document less clear. My apologies for that. Does the following make more sense: +-++-+ | content|| content| |-||-| | syslog application || syslog application | (originator, | || | collector, relay) |-||-| | syslog transport || syslog transport | (transport sender, | || | (transport receiver) +-++-+ ^ ^ | | -- In this, the content will be developed by some application and handed to syslogd (using *nix as an example device). syslogd will format the message adding in the PRI, timestamp, etc., and will hand it to the transport. - For udp transport, the transport sender will encapsulte it within udp and put it onto the wire. - For the case of tls, the transport sender will establish a new, or use an existing session with the transport receiver. For discrepancies (if any) between the IP address of the originator and the transport sender, the originator can use the [origin ip=...] SDE (Section 7.2). If this makes sense, then the mib counters can be: - the number of messages sent and received by the syslog application (syslogd) - the number of messages sent and received by the transport sender and transport receiver. The tricky part here is that the counters of the transport sender and transport receiver are not going to be useful to counting messages that are relayed. Only the counters of the syslog application are going to be useful for that. To deal with that, I'll propose that that a table be set up to associate the messages sent to each relay destination. As an example from syslog.conf: kern.crit@loghost kern.info@loghost2.example.com The relay destinations will have to be enumerated. get numOfRelayDests would return 2 get relayDest(1) would return loghost get relayDest(2) would return loghost2.example.com What is to be sent to those destinations would have to be quantified. get priOfRelayDest(1) would return 2 (from kern.crit as the filter) get priOfRelayDest(2) would return 6 (or kern.info) When the device receives a 2... syslog message (PRI=2, kern.crit), it will relay it to the two
Layer diagram mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20
Hi All, What I'm seeing is that our effort to add granularity for mib accounting has made the document less clear. My apologies for that. Does the following make more sense: +-++-+ | content|| content| |-||-| | syslog application || syslog application | (originator, | || | collector, relay) |-||-| | syslog transport || syslog transport | (transport sender, | || | (transport receiver) +-++-+ ^ ^ | | -- In this, the content will be developed by some application and handed to syslogd (using *nix as an example device). syslogd will format the message adding in the PRI, timestamp, etc., and will hand it to the transport. - For udp transport, the transport sender will encapsulte it within udp and put it onto the wire. - For the case of tls, the transport sender will establish a new, or use an existing session with the transport receiver. For discrepancies (if any) between the IP address of the originator and the transport sender, the originator can use the [origin ip=...] SDE (Section 7.2). If this makes sense, then the mib counters can be: - the number of messages sent and received by the syslog application (syslogd) - the number of messages sent and received by the transport sender and transport receiver. The tricky part here is that the counters of the transport sender and transport receiver are not going to be useful to counting messages that are relayed. Only the counters of the syslog application are going to be useful for that. To deal with that, I'll propose that that a table be set up to associate the messages sent to each relay destination. As an example from syslog.conf: kern.crit@loghost kern.info@loghost2.example.com The relay destinations will have to be enumerated. get numOfRelayDests would return 2 get relayDest(1) would return loghost get relayDest(2) would return loghost2.example.com What is to be sent to those destinations would have to be quantified. get priOfRelayDest(1) would return 2 (from kern.crit as the filter) get priOfRelayDest(2) would return 6 (or kern.info) When the device receives a 2... syslog message (PRI=2, kern.crit), it will relay it to the two relay destinations. Then syslogOperationsMsgsReceived will be incremented by 1 syslogOperationsMsgsRelayed(0) will be incremented by 2 (the message went to two destinations) syslogOperationsMsgsRelayed(1) will be incremented by 1 (it sent one copy to relayDest(1) which is loghost) syslogOperationsMsgsRelayed(2) will be incremented by 1 (it sent another to relayDest(2)) syslogOperationsMsgsTransmitted will be incremented by 2 (it transmitted both) Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1 and on loghost2.example.com syslogOperationsMsgsReceived will also be incremented by 1. This gives an administrator a way to balance out messages sent and received. - If our device shows 3 messages relayed to loghost, and loghost shows 3 messages received, then we have a balance, even if MsgsTransmitted from our device is 482. - If our device shows 3 messages relayed but loghost shows 2 messages received, then we might have a discard on our device, or the message may have been dropped by some intermediary. - If our device shows 3 messages relayed but loghost shows 46 receieved then we likely have another device sending messages to loghost. To be clear on this, the counters for transport sender and transport receiver will NOT be associated with a peer - they will just count the number of messages sent and received. It will be up to the counters associated with the syslog application to associate the messages with peers so that the count of messages relayed will have some meaning. Does this make sense? As David said, we're not doing our job unless we're clear on the concepts, terminology and have a way to manage the devices. Thanks, Chris On Fri, 18 May 2007, tom.petch wrote: Not sure where this draft is heading, but as a WG member, comments inline Tom Petch ---remainder elided for brevity--- ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] FINAL review of draft-ietf-syslog-protocol
Hi Tom, The credit goes to Rainer who put in the time and effort. :-) I have found these minor nits as well: === A.2 Implementers should note the message size limitations outlined in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length). This ensures the data will be seen by the collector or relay even if the receiver at a relay on the message path truncates the message. ...even if the reciever _as_ a relay on the message path... s/confusability/confusion/ s/dcument/document/g === These can be corrected in AUTH48. draft-ietf-syslog-protocol and draft-ietf-transport-tls are back in Sam's hands. I expect an upcoming telechat will move them forward. They don't need to wait for transport-tls to be sent to the RFC Editor, but the RFC Editor won't publish them until all normative references are in good standing. I have the latest draft-ietf-syslog-transport-tls and just finished my review of it last night. I believe that it addresses all of Sam's concerns. I'm going to ask Miao and Yuzhi to submit it to the ID editor so we can review in the WG. I appreciate your review. Thanks, Chris On Fri, 11 May 2007, tom.petch wrote: Chris I looked some more and am happy with it; the changes are thorough and comprehensive. I did wonder about the use of device which used to have a technical meaning in early versions of the I-D and now I take not to have. 'Machine' is I think used in the same sense, of the box/stack in general without any more specific meaning and that seems fine. One minor nit grabbed me, an extra comma in s.1 in reliable, and secure syslog extensions suffer from the lack of a where the comma is absent in the same sentence in the Abstract. I take it we are still awaiting a further -tls for review before the three of them go to the rfc-editor. Tom Petch - Original Message - From: tom.petch [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, May 04, 2007 4:37 PM Subject: Re: [Syslog] FINAL review of draft-ietf-syslog-protocol Chris I have looked at this and will look at it again in more depth next week. Some of the new terminology in s.3 is unfamiliar to me and, while the end result is not as complex as say RFC3411, it is still going to take a while for me to grasp (by inference) the role of eg parser and formatter, the (redefined) sender and receiver, and to work out which is responsible for which bits on the wire and see if the usage hangs together. The changes are more extensive than I anticipated. Probably, they much improve the precision but, at first sight, I am less certain about the increase in clarity. Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 02, 2007 10:45 PM Subject: [Syslog] FINAL review of draft-ietf-syslog-protocol Hi Folks, David and I would like to hand off this final version to Sam for publication by Friday. I have performed an initial review and feel that the changes address the IETF Last Call items. The changes requested from the IETF Last Call were: Item 1) Severity Range - The range of the Severity is not bound. The WG decided that it needs to be bound in the range of 0 to 7 inclusive. Item 2) Language Tags - BCP47 (RFC 4646) is the IETF standard for language tags. The document needs to be compliant with this standard. Section 7.3.3 specifies the use of ISO 639 (which was the only reference available at the time we discussed languages in the mailing list.) Sam asked that we need to change the language tags to BCP47 to justify our decision. I've found no compelling reason to continue to use the ISO 639 tags. We need to change that paragraph to state that BCP47 language tags will be used. The current MAY in Section 7.3.3 should still be used. Item 3 - Deadlocks - There was a lengthy discussion about using a reliable delivery mechanism for syslog and how certain circumstances could cause the loss of messages. (I personally felt it was not addressing any normative text in the document.) A note about deadlocks in Section 8.5 has been requested by Sam. This will need to be short. Item 4 - IANA - We should review the document to see if there are any IANA registry values that may be revised by IETF Consensus rather than Standards Actions. I'll make a review and let you know if I find anything. Item 5 - Definitions - The definitions of sender receiver relay, originator and collector need to be tightened up. They are somewhat inconsistent now and are required by the -device-mib document. You may view the differences between -19 and -20 here: http://tools.ietf.org/wg/syslog/ Click on draft-ietf-syslog-protocol and select your method of seeing the diffs from -19. Please submit any comments you have to the WG that concern how Rainer addressed these issues in this document. Thanks, Chris
Re: [Syslog] SDE proposals
Hi, David is correct in this. No matter how strongly we feel that defining SDEs for other applications is good work, it will not be done in this WG. For documents that describe new SDEs, the alternatives to forming a new WG are: - have SDEs defined in a WG that is already dealing with that application - produce individual contribution documents and get the support of an Area Director to turn them into RFCs. Please keep in mind that draft-ietf-syslog-protocol lists the IETF Consensus method for adding new SDEs. From RFC 2434: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). Thanks, Chris On Tue, 1 May 2007, David Harrington wrote: Hi, As syslog WG co-chair, let me make the WG aware of this point. Standardization of structured data elements (SDEs) is out of scope for this WG. The syslog WG is a **security** WG, not a data modeling WG. The protocol document describes the fact that IANA-registered SDEs should be approved by Standards action. That is for (IETF-sponsored) IANA-registered SDEs only. Individuals can define their own SDEs (containing an at-sign) that are not IANA registered. We have had a couple drafts brought to this WG that define SDEs. If members of this WG want to standardize SDEs, they should request the creation of a WG in the OPS area to do that work, or if the SDEs relate to a specific type of SDEs, such as those related to RAI technologies, you might be abel to start a WG in the associated area. You will probably need to develop a charter, with document deliverables, timelines within which the documents will be delivered, and limits on which types of SDEs will be developed within the documents. Charters can be renewed to develop new documents for SDEs with different focus over time. Personally, I think defining and registering standard SDEs would be very valuable work. However, the syslog WG in the Security Area is not the correct WG to host this work. 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
Re: [Syslog] Syslog-tls-09 draft - suggested change
Hi, On Tue, 24 Apr 2007, Eliot Lear wrote: Miao, TLS is still duplex even if syslog is simplex. In the same time, authenticaiton happens in the handshaking phase of TLS when syslog message transfering does not begin . So, simplex or duplex does not matter for authentication. I personally haven't liked those terms since 300 baud modems and 3270s went out of style ;-) I had persuaded myself that syslog sender is always hosted on automated application/appliance, such as web daemon or printer, this make it impossible for an user to check interactively whether umatched hostname/IP address is acceptable. However, I am suspecting the perception is wrong. It is possible to host syslog sender on a interactive application, such as database administration tool. This is not as simple a decision as may first appear. On the one hand, while you can come up with examples such as the above, and they really do exist (another good one is when you have some sort of Windows Watcher(*) that you want to log back to a central source), the two problems with reporting to the user are (a) the cases where there is no user and (b) the fact that operational experience has shown that the user really doesn't know what to do when there is a problem. On the other hand, we have another little problem in this specific case. What do we normally say when something goes wrong in one of our protocols? Log an error. Here that poses a little bit of a problem ;-) I would suggest text along the lines of the following: The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. In the case of a receiving relay or a receiver, the connection SHOULD be closed and an error logged, indicating the problem. In the case of a syslog sender or a transmitting relay, the situation requires more care. Here the application SHOULD also close the connection and also use whatever other means are available to it to inform the administrator of the problem. This may include producing a message on a console, returning an error to the user, or writing a file to disk, if possible. There is also a matter of what an application is supposed to do when logging fails. Some applications should proceed uninterrupted. Others may need to block. I don't know whether text is appropriate. It's not part of the protocol, but it does fall under common modes of failure. The reason this would be an issue with TLS (or BEEP for that matter) and not with UDP is that one doesn't block with UDP. I think Eliot is on the right track. However, I wouldn't differentiate between the actions that a sender or receiver is to take when authentication fails - both cases should have a recommendation that the device log the failure _and_ attempt to inform the administrator of the problem. This might be pop-ups to the unsuspecting user who won't know what to do about it, it might be messages printed on the console, it might be a blinky light on the printer, etc. (Most networked printers that I'm seeing these days have nice displays that are starting to give informative messages.) Perhaps this text: The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. The connection SHOULD be closed and an error logged indicating the problem. Since this problem will prevent log messages from being transmitted, each device having this problem should use whatever means are available to inform the administrator of the problem. This may include producing a message on a console, returning an error to a user (if there is one), or writing a file to disk, if possible. In addition, you have another problem in the text: If the client is configured with IP address of the server, the hostname should be got first through a trusted mechanism such as a preconfigured hosts table or DNSSEC [8]. It is often the case that a reverse map does not match a forward map. For example, often times a service provider might allocate IP address space and route that space to a customer but not delegate the reverse mapping. This is particularly true in consumer environments. I would suggest that if the client is configured with an IP address, that it is what should be present in the certificate, as the name has no meaning at all to the client. I think that's an operational issue that we're not going to deal with. We're talking about a domain of administration here. We're not going to be able to write enough text into this document to cover the case where the administrators cannot line up dNSName with an IP address within their own purview. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org
Re: [Syslog] Syslog-tls-09 draft - suggested change
Hi, I'm OK with this proposal with two minor changes. - rather than (see below) it should have (see next paragraph) - remove parenthasis from (with a bad certificate error) as that text is normative. vv If the hostname does not match the identity in the certificate, clients SHOULD log the error in some form or another (see below), and SHOULD terminate the connection (with a bad certificate error). Clients MAY provide a configuration setting that disables this check but MUST enable it by default. The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. Since this problem will prevent log messages from being transmitted, each device having this program should use whatever means are available to inform the administrator of the problem. This may include producing an error code on a console, returning an error to a user (if there is one), or writing a file to disk, being mindful that such writes should be rate limited in the case of attacks. ^^ Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Status Update
Hi Folks, I know that the mailing list has been quiet for a while. This doesn't mean that we're not working. :-) We have taken the IETF Last Call comments and asked Rainer to integrate them into -protocol. As we've discussed, the definitions in -protocol needed to be slightly reworked so that the counters in -mib have specific meaning. We can't have any ambiguity in how things are counted in -mib so we need to be very specific in -protocol. We think we have a clear set of definitions now and Rainer is integrating those items into -protocol. We should see the revision soon. We've also asked Glenn to make some revisions to -mib to be consistent with -protocol and so that the accounting of packets will work out. Miao and Yuzhi are integrating the IETF Last Call comments into -transport-tls. They submitted that to the ID Editor a day or so ago but David noticed an error that needs to be rectified before we ask the WG for final review. Anton worked-in the IETF Last Call comments and we're satisfied that it is ready to go. Alex is preparing a new ID to address many of the comments received about -sign. We'll be asking for a review of that when it is updated. Somehow the -3195bis ID got dropped from our list of IDs. We've asked Eliot to resubmit that. Once we get that in the repository we can review it. Thanks, Chris David ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] New -transport-tls ID - Need Reviews NOW
Hi Folks, New ID: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-07.txt Miao has submitted a revised -transport-tls document. This came about after Sam performed a review and found some items that needed to be addressed. From Sam: ===vvv=== First, I think the idea of generic certificates will not meet with consensus of the security community. It may be OK to use the same Subject name for all cable modems from a given vendor, but reuse of private keys is not something we should recommend in an IETF standard. In general, preferring dnsname subjectAlternativeName to CN in the subject field seems preferable. Why does this specification use cn rather than either always using dnsname or using a procedure similar to that in RFC 2818. The text seems confused about what authentication is required when. Section 5.1 implies that authentication of receivers is optional but the text requires it. Are senders and relays required to have a certificate and to use that certificate? ===^^^=== There is a lengthy discussion which can be found in the archives. David and I feel that there are enough significant changes to this document that we'd like a WG review before we pass it back to Sam. Please read this document and send a note back the the mail list - even to say that you have no problems with the document. I'll ask that everyone overlook typo's and small grammar problems at this time. We need to make sure that the document: - addresses Sam's concerns, - meets the stated goals of our charter, - is technically sound, implementable, and deployable, - is a good thing to do for syslog. Many thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Consensus - was: Re: [Syslog] RFC 3164 in syslog-sign? (fwd)
Hi, Overwhelming consensus is that references to 3164 will be removed from syslog-sign. Alex, Please start working on this but don't submit any changes until after WGLC is complete on 28 Dec. All: Please continue to review the document and let's get this out the door. Thanks, Chris P.S. - Seasons Greetings to All and my very best wishes to everyone for a happy and prosperous New Year. :-) ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RFC 3164
Hi, The Chairs have spoken to the author of RFC 3164. The author agrees that it should be OBSOLETED. ;-) I did discuss this with someone who has been trying to de-cruft a lot of ancient RFCs. It is not usual to OBSOLETE an INFORMATIONAL RFC but there's nothing that says that we can't do it. When syslog-protocol gets into the RFC Editors queue, I will tell them to OBSOLETE RFC 3164 with that document. Thanks, Chris On Fri, 22 Dec 2006, Rainer Gerhards wrote: 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
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_guide09186a00807883c3.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
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. 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. 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. 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 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
[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
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; 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. -- Version field: I recommend renaming it to something like Sig-Version to avoid mistaking -protocol VERSION and -sign Version. There are actually two Version fields. The first is an SD-Param called VER in the SD-ID of ssign. The second is an SD-Param, also called VER, in ssign-cert. This type of duplication is acceptable in the rules of syslog-protocol. I can't think of any way that it could be confused with the version number in the header of the syslog message. -- I hope I will be able to do a full review by the end of the week. Looking forward to it. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Hi, In the following, [14] is syslog-protocol [15] is syslog-transport-udp [16] is syslog-transport-tls === Last paragraph in the Introduction This specification is independent of the actual transport protocol selected. The mechanism is especially suitable for use with the syslog protocol as defined in RFC [14] because it utilizes the STRUCTURED-DATA elements defined in that document. It may also be used with syslog packets over traditional UDP [4] as described in RFC 3164 [10]. It may also be used with the Reliable Delivery of syslog as described in RFC 3195 [11], and it may be used with other message delivery mechanisms. Designers of other efforts to define event notification mechanisms are encouraged to consider this specification in their design. Would it be better to RECOMMEND this mechanism be used with [14]? That would be consistent with the RECOMMENDation in Section 3. === Fourth paragraph in Section 3: When used in conjunction with RFC [14], the syslog messages defined in this document carry the signature and certificate data as STRUCTURED DATA, as defined, while the MSG part of the syslog messages is simply empty - the contents of the messages is not intended for interpretation by humans but by applications that use those messages to build an authenticated log. Would it be better to state that the MSG part of the message MUST be empty? It's suggested here but not explicitly stated. === From Section 4.1 A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, as value for APP-NAME, syslog (without the double quotes) MUST be used. As value for MSG-ID, sig (without the double quotes) MUST be used. As value for the PRI field, 110 MUST be used, 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. 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. === Section 4.2.7 gives the definition of the syslog message that needs to be hashed: starting with the of the PRI portion of the header part of the message and ending with the Unicode byte order mask, BOM. That needs to be changed as the BOM is not the end of the message. === The count for ssign is a maximum of 2-bytes and is a value of between 1 and 99. This will likely fit into a message with a length of 2048 octets as stated in Section 4.2.7 if the hashes are 160-bytes. Is this acceptable to the group? We started this with the idea that this mechanism would be run atop RFC 3164 with a maximum length of 1024 octets. However, would a greater efficiency be gained by increasing the length of the syslog-sign message and the length of the Count? === The word monotonically increasing is used in a few places. I think that we're actually trying to say sequentially increasing. === The SD-ID values in Section 9 (IANA Considerations) need to be in tables so that the IANA can cut-n-paste. === Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] severity
Hi, Rainer has it right. I agree that a simple note as Rainer suggests will do it. Thanks, Chris On Fri, 15 Dec 2006, Rainer Gerhards wrote: 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 mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Diffs in syslog-sign IDs
Hi Folks, There have been many changes made to the syslog-sign ID during the last WGLC. As David announced, we are going to do another WGLC for this ID. To help you in your reviews, I have created some diffs. The differences between -18 and -19 http://www.employees.org/~lonvick/sign-18-19.html The differences between -19 and -20 http://www.employees.org/~lonvick/sign-19-20.html The differences between -18 and -20 http://www.employees.org/~lonvick/sign-18-20.html Please review and send in your comments. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Submission of Shepherding Documents
Hi Folks, David and I are pleased to announce that the shepherding documents for the following IDs have been submitted to the IESG. - draft-ietf-syslog-protocol-19.txt - draft-ietf-syslog-transport-tls-06.txt - draft-ietf-syslog-transport-udp-08.txt Our thanks go to the authors and the Working Group for putting in the time and effort to develop and review these documents. We now need to focus on getting syslog-device-mib and syslog-sign out the door. Many thanks, Chris David ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Updated IPR disclosure
Hi All, Cisco legal counsel has reviewed this and found it to be acceptable and written consistent with most other IPR statements. Again, Cisco thanks Huawei for addressing this issue. Thanks, Chris On Mon, 27 Nov 2006, Chris Lonvick wrote: Hi Everyone, Cisco asked Huawei to make this change. Essentially the prior statement appeared to be similar to the IPR statements made by Cisco and other companies but it had differences that were not acceptable to the Cisco legal team. Hence, Cisco would not have been willing to implement the standard produced. Huawei's legal team looked into this and they have made these changes. The new statement appears to me (as David says, we are not lawyers) to be much closer to the intent of Cisco's, and others, IPR statements. I'm asking Cisco's legal team to review this and I will post Cisco's response when I have that. (Working Group Chair Hat OFF): On behalf of Cisco, I would like to thank Huawei for addressing this issue. I must note once again that the IETF will not make any determination of the validity of any IPR claimed. Huawei has been following the IETF rules on disclosure and statement of terms. Thanks, Chris On Mon, 27 Nov 2006, David Harrington wrote: Hi, The syslog WG co-chairs were notified that a request was being made to Huawei by a company experienced in IETF IPR disclosures, that Huawei modify their terms related to the TLS transport document. Huawei has chosen to change their terms as requested. The new terms can be seen at https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=763 The new disclosure is relevant to tls-03. We have requested Huawei to also post an update relevant to tls-04, which was just published. The changes apparently are meant to tighten the language a bit, and to make Huawei terms more consistent with those of other companies filing disclosures within the IETF. The co-chairs are not lawyers, and cannot provide legal advice about the changes. The WG needs to consider whether the modified terms are acceptable for this document to be advanced to the standards-track. Please send your comments to the co-chairs as soon as possible. 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] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt
Hi Tom, Noted. I'll add that and should have a new shepherding document out later today. Thanks, Chris On Thu, 30 Nov 2006, tom.petch wrote: Chris I would say that there was controversy about the use of ports and that that should be reflected in the shepherding document. I would not be surprised to see this issue come up in IETF Last Call and it would be better to show that we had at least considered it. Something along the lines of There was also some controversy about the use of a dedicated port for this, initial version of syslog over TLS; the consensus was that a dedicated port should be requested and that there should be no indication of version with the consequence that any future change to the protocol might require a different port number. Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 5:12 PM Subject: [Syslog] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt Hi, Please review this and the latest version of the document. Send in any comments very soon as we would like to submit this to the IESG by Friday. If I don't hear anything, then this will become the final shepherding document. Thanks, Chris === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-05.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick clonvick at cisco.com === (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 clonvick at cisco.com 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 most of them were fixed in version -04. A very few minor issues were also addressed from that which resulted in vresion -05. 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? Normative reference
Re: [Syslog] Towards closure of syslog-tls issues
Hi Miao, I agree that these should be in the ID before submission to the IESG. Please make these changes for version -06 and submit to the ID Editor. Once these are in I will submit to Sam and the IESG. Go ahead and take care of the other minor nits that are pointed out in the shepherding document for -05 as well. Thanks, Chris On Thu, 30 Nov 2006, tom.petch wrote: Chris I agreed (mostly) with the actions in your e-mail but do not see them all reflected in -05. See inline 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 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 This I see, at least the latest RFC part - note that the latest ciphers and their relative strengths may be found in BCP86 This I do not see and would like to - note that implementors and deployers should keep aware of current literature Likewise, this I do not see and would like to (This should be about 3 sentences.) snip Please make these changes and submit -05 so we can submit this to the IESG. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Near Final Shepherding Document for draft-ietf-syslog-transport-tls-05.txt
Hi, Please review this and the latest version of the document. Send in any comments very soon as we would like to submit this to the IESG by Friday. If I don't hear anything, then this will become the final shepherding document. Thanks, Chris === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-05.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-transport-tls-05.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick clonvick at cisco.com === (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 clonvick at cisco.com 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 most of them were fixed in version -04. A very few minor issues were also addressed from that which resulted in vresion -05. 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? Normative reference [3] is not used in the document. This reference will be dropped by the RFC Editor during AUTH48. There is an extraneous blank line in the Acknowlegements section which will be removed during AUTH48. === (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 draft-ietf-syslog-protocol-19.txt which is being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration
[Syslog] Near final shepherding document for draft-ietf-syslog-protocol-19.txt
Hi Folks, Rainer has submitted version -19 of syslog-protocol to the ID Editor. We should see it tomorrow. It is identical to the version -18 except that the ITU Alarm MIB table has been removed. We do have a volunteer to write that in a separate document but we will not have an initial version of that before this document goes to the IESG. Please review this and give me comments back as soon as you can. I would like to submit this to the IESG tomorrow or Friday. Thanks, Chris === Having passed a WG Last Call, draft-ietf-syslog-protocol-19.txt is ready for AD review. [Area] SECURITY [WG] syslog [I-D] draft-ietf-syslog-protocol-19.txt [Qver] draft-ietf-proto-wgchair-doc-shepherding-08.txt [Shep] Chris Lonvick clonvick at cisco.com === (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 clonvick at cisco.com 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 (-17 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/msg01243.html Richard Graveman's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01240.html Sharon Chisolm's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01232.html Tom Petch's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01167.html David Harrington's review http://www1.ietf.org/mail-archive/web/syslog/current/msg01144.html The issues raised in these reviews have been discussed on the mailing list and most of them were fixed in version -18. A very few minor issues were also addressed from that which resulted in vresion -19. 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? No. === (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. None. === (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? I have reviewed the document. Section 12 is a Note to the RFC Editor to say that other documents are dependent upon this one. This will be dropped by the RFC Editor. Reference [10] is unused and will be removed by the RFC Editor or during Auth48. === (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
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
[Syslog] Re: Updated IPR disclosure
Hi Everyone, Cisco asked Huawei to make this change. Essentially the prior statement appeared to be similar to the IPR statements made by Cisco and other companies but it had differences that were not acceptable to the Cisco legal team. Hence, Cisco would not have been willing to implement the standard produced. Huawei's legal team looked into this and they have made these changes. The new statement appears to me (as David says, we are not lawyers) to be much closer to the intent of Cisco's, and others, IPR statements. I'm asking Cisco's legal team to review this and I will post Cisco's response when I have that. (Working Group Chair Hat OFF): On behalf of Cisco, I would like to thank Huawei for addressing this issue. I must note once again that the IETF will not make any determination of the validity of any IPR claimed. Huawei has been following the IETF rules on disclosure and statement of terms. Thanks, Chris On Mon, 27 Nov 2006, David Harrington wrote: Hi, The syslog WG co-chairs were notified that a request was being made to Huawei by a company experienced in IETF IPR disclosures, that Huawei modify their terms related to the TLS transport document. Huawei has chosen to change their terms as requested. The new terms can be seen at https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=763 The new disclosure is relevant to tls-03. We have requested Huawei to also post an update relevant to tls-04, which was just published. The changes apparently are meant to tighten the language a bit, and to make Huawei terms more consistent with those of other companies filing disclosures within the IETF. The co-chairs are not lawyers, and cannot provide legal advice about the changes. The WG needs to consider whether the modified terms are acceptable for this document to be advanced to the standards-track. Please send your comments to the co-chairs as soon as possible. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Draft Shepherding document for draft-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 draft-ietf-syslog-transport-udp-08.txt and draft-ietf-syslog-protocol-18.txt which are being submitted along with this document. === (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry
RE: [Syslog] Draft Shepherding document fordraft-ietf-syslog-transport-tls-04.txt
Hi Rainer, inline On Wed, 22 Nov 2006, Rainer Gerhards wrote: 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 draft-ietf-syslog-transport-udp-08.txt and draft-ietf-syslog-protocol-18.txt which are being submitted
[Syslog] Alarm MIB in syslog-protocol
Hi, In David Harrington's review of syslog-protocol-17 http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We discussed this a while ago and it doesn't seem that there is a good fit between the historical syslog severities and the Alarm MIBs. I've asked Rainer to remove this. Anyone interested is hereby encouraged to write a document that specifies how to display the Alarm MIBs as Structured Data. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Alarm MIB in syslog-protocol
Hi Sharon, It's an important concept but I feel that it is underspecified and ambiguous in the current document. The recipent of a message with the Severity of Notice would not be able to tell if the sender intended for it to be the ITU alarm of Indeterminate or Cleared. I believe that this part was specified before the concept of Structured Data was included in syslog-protocol. Using Structured Data would disambiguate the intention. Thanks, Chris On Fri, 3 Nov 2006, Sharon Chisholm wrote: Hi This is an important section (and no, I'm not just saying that because I co-authored RFC 3877). It provides the mapping between severities in alarms sent via SNMP and those logged in syslog. Removing it means that implementations will all have different mappings. Sharon -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 12:34 PM To: [EMAIL PROTECTED] Subject: [Syslog] Alarm MIB in syslog-protocol Hi, In David Harrington's review of syslog-protocol-17 http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We discussed this a while ago and it doesn't seem that there is a good fit between the historical syslog severities and the Alarm MIBs. I've asked Rainer to remove this. Anyone interested is hereby encouraged to write a document that specifies how to display the Alarm MIBs as Structured Data. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Alarm MIB in syslog-protocol
Hi Sharon, On Fri, 3 Nov 2006, Sharon Chisholm wrote: Hi Actually, no structured data was already in the draft when this was added. At the time, the working group discussed the lossy nature of the mapping, determined it was inevitable, looked at the various ways the mapping could be constructed and settled on the one which lost the least important bit of information. Perhaps a note indicating that this mapping is lossy and that implementations that want to be able to do a fully reversible mapping should consider also sending the alarm/ITU severity within the syslog message. I don't believe we need to indicate how in this document. Just indicate that we recognize the issue and hint at how to solve it. Sort of like a security considerations section. We have a mechanism defined to address the issue properly. Why would we want to underspecify this standard (syslog-protocol) by just giving a hint of how to do it right? If it is going to be done, then it needs to be done properly and completely, which means fully specifying how to indicate the true ITU severity within structured data. However, I don't want to delay this document by doing it here at this time. What's wrong with putting this in a separate document? Thanks, Chris Even if people have some extra field, they still need to know what to do with the severity field syslog. I view this as no different then the mapping to ifAdmin and ifOper status we did when we did the Entity State MIB. http://www.ietf.org/rfc/rfc4268.txt?number=4268 Sharon -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 1:26 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Alarm MIB in syslog-protocol Hi Sharon, It's an important concept but I feel that it is underspecified and ambiguous in the current document. The recipent of a message with the Severity of Notice would not be able to tell if the sender intended for it to be the ITU alarm of Indeterminate or Cleared. I believe that this part was specified before the concept of Structured Data was included in syslog-protocol. Using Structured Data would disambiguate the intention. Thanks, Chris On Fri, 3 Nov 2006, Sharon Chisholm wrote: Hi This is an important section (and no, I'm not just saying that because I co-authored RFC 3877). It provides the mapping between severities in alarms sent via SNMP and those logged in syslog. Removing it means that implementations will all have different mappings. Sharon -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 12:34 PM To: [EMAIL PROTECTED] Subject: [Syslog] Alarm MIB in syslog-protocol Hi, In David Harrington's review of syslog-protocol-17 http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877). We discussed this a while ago and it doesn't seem that there is a good fit between the historical syslog severities and the Alarm MIBs. I've asked Rainer to remove this. Anyone interested is hereby encouraged to write a document that specifies how to display the Alarm MIBs as Structured Data. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] enc param in syslog-protocol
Hi All, I've been reviewing the use of enc (for defining the encapsulation type). This discussion has been going on for some time. http://www.mail-archive.com/syslog@lists.ietf.org/msg00241.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00252.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00300.html http://www.mail-archive.com/syslog@lists.ietf.org/msg00313.html I know that several people would like a way to send binary data within syslog messages and that's what this param was intended for. However, without actually defining other encapsulation types, the parameter appears to be underspecified. I don't want this to hold up our effort at this time. I'm going to ask Rainer to remove references to enc from syslog-protocol. Once this standard is out, others can discuss other encapsulation types and put together a document that fully describes it and how it can be used to ship binary information, or other encapsulation types. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: syslog/tls - how to abort because of inconsistent versions
Hi Miao and All, We had a discussion with Eric Rescorla (as a technical expert) about the use of a TLS alert to signal a version exchange problem. He recommended that TLS alerts are to be used by TLS and should not be used for signalling of upper-layer events. From that, we should not be considering #1 below. For #3, we are not going to examine the simplex nature of syslog for each new transport. That work has been done in RFC 3195. I recommend that we go with #4. This seems to be no different from current implementations of syslog/udp. In this, it is always wise to check that messages are being received from a syslog sender since the sender gets no indication that the message has been received from the server. It would be appropriate for the document to note this in the security considerations section and perhaps to even point out that #2 is a viable step. I would like to close this out very soon. Please comment back to the list if you have an opinion on this. Thanks, Chris On Mon, 23 Oct 2006, Miao Fuyou wrote: Hi, There are several possible options to solve this issue: 1, Using a TLS alert to signal the inconsistent versions as the current draft does. The drawback is it violate the layer, using TLS alert to notify an application event seems ugly. 2, Saving the data (TLS app-data, not syslog message, different to UDP transport) no matter what the version is. This may mean a receiver should be able to save a stream without any knowledge about the structure of the stream. The data can not be stored in the same file/database to the one for syslog messages, because it has no way to delimit frames. 3, Change the simplex of syslog, add an application level notification from receiver to sender, this may increase the effort of implementation greatly, 4, Do nothing, the sender may keep connecting the receiver. But, we can recommend in that specification like if connections are closed just after successful TLS handshake for three times with same transport mapping version, the sender SHOULD not connect the receiver again with the same transport version. Does it work? My preference is 4 1 2 3. Miao -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 2:55 AM To: Miao Fuyou Cc: 'David Harrington'; [EMAIL PROTECTED] Subject: RE: syslog/tls - how to abort because of inconsistent versions Hi Miao, We need this issue resolved in the WG. Please bring up the discussion on the list with a proposal. I suggest that we not use TLS to signal a failure in the upper level. Thanks, Chris On Thu, 19 Oct 2006, Miao Fuyou wrote: Hi, Eric, One clarification to version #: syslog/tls version is the one for syslog/tls transport mapping, but syslog version # is the one for syslog-protocol, they are diffirent numbers. When a receiver gets a message with a **syslog version number** it does not understand, it could save the message in local storage or forward to other receiver because it know exact the boundary of the message (actually a receiver does not have to understand the version of syslog protocol in most cases, because the only task for receiver is to store or forward). But, this may not apply to syslog/tls transport mapping. Diffirent **syslog/tls version number** may mean diffirent APP-DATA format. A receiver with a diffrent version may not be able to parse the stream or delimit syslog messages, the only thing that it can do is to save the tls stream in local storage if it is linient. But, saving stream seems ugly, maybe more ugly than making tls alert to serve application:-) Thanks! Miao -Original Message- From: EKR [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 10:02 AM To: Miao Fuyou Cc: 'David Harrington'; [EMAIL PROTECTED]; 'Chris Lonvick' Subject: Re: syslog/tls - how to abort because of inconsistent versions Miao Fuyou [EMAIL PROTECTED] wrote: Hi, Eric, The primary reason to use a TLS level notification to notify an event for application level is to keep Syslog still simplex, but it seem violative to clear layership. An application notification will change that simplex of syslog, which is alien to syslog. The wg is in the dilemma to process this issue. Your sugestion? Well, I see that draft-ietf-syslog-protocol-17.txt contains a version #. What do you do if that is something you don't understand? -Ekr ___ 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 over ssh - was: [Syslog] RE: Request for Reviewers - draft-ietf-syslog-transport-tls-03.tx t
Hi Bert, We appreciate your review of the document. As for syslog-over-ssh: We had been incontact with the ISMS and Netconf WGs and we did see that they had chosen SSH as a secure transport. We did discuss this within our own Working Group. The consensus was: - there are current implementations of syslog-over-ssl - ssh uses the concept that there is an interactive user which works well for ISMS and Netconf. However, syslog does not have a concept of a user but is more associated with the idea that this is an automated function of the device which works better with tls authentication mechanisms. With that said, I believe that there is interest from some members of the WG to pursue syslog-over-ssh and in fact, a starting point has been made with draft-gerhards-syslog-transport-ssh-00.txt We are under a tight timeline and since the topic has been discussed and agreed to in the past, we will complete the syslog-over-tls work. Thanks, Chris On Tue, 10 Oct 2006, Wijnen, Bert (Bert) wrote: -Original Message- From: Wijnen, Bert (Bert) Sent: Monday, October 09, 2006 16:29 To: [EMAIL PROTECTED] Subject: RE: Request for Reviewers - draft-ietf-syslog-protocol-17.txt David Harrington (co-chair of the Syslog WG) specifically asked me for a review of documents in WG Last Call. I am not subscribed to the SYSLOG WG mailing list, so pls copy me explicitly on any reactions that you want me to see. I am not a security expert, and this WG is in the Security Area, so I am assuming that the security aspects are well reviewed by the respected WG members or colleagues in the SEC area. I also have a common/generic question: The ISMS and NETCONF WGs have defined as manadatory to implement SNMP-over-SSH and NETCONF-over-SSH. I think it would be really really good/best if the SYSLOG WG would also define a mandatory to implement SYSLOG-over-SSH, so that operators can use one and the same security infrastructure for the operational management and monitoring of their systems. In other words, I find it a pitty that the WG charted work-item: - A document will be produced that requires a secure transport for the delivery of syslog messages. Did not result in a mapping over SSH. Bert - draft-ietf-syslog-transport-tls-03.txt I am not sure I understand what this means (sect 4, last para): 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. I thought the porimary goal was to secure messages from draft-ietf-syslog-protocol-17 but I don;t see that mentioned in sect 4. Bert --- original review message: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-17.txt Transmission of syslog messages over UDP http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-07 .txt TLS Transport Mapping for SYSLOG http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt Syslog Management Information Base http://www.ietf.org/internet-drafts/draft-ietf-syslog-device-mib-09.tx t Signed syslog Messages http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-18.txt (We expect this document to be updated this week.) 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] Diffs on -protocol and -transport-udp
Hi Folks, We need some more reviews of our documents. There has been some discussion that the documents havn't changed much since the last time we went through a WGLC. I've made some diffs of -protocol and of -transport-udp so you can see what changes have been made. Diff from protocol-14 and protocol-17 http://www.employees.org/~lonvick/diff-14-17.html Diff from transport-udp-05 and transport-udp-07 http://www.employees.org/~lonvick/diff-udp-07-05.html Please look these over and comment to the WG list that you have done so. At a minimum your review to the group should be that you have read the document and are satisfied with its quality and content that it can become an RFC. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document
Hi Bazsi, On Thu, 7 Sep 2006, Balazs Scheidler wrote: On Thu, 2006-09-07 at 17:17 +0800, Miao Fuyou wrote: Starting from TCP and then upgrading to tls is quite different to current tls transport mapping document. If we decide to do UPGRADING, we may first need a TCP transport mapping for Syslog, and then define a specific string to indicate the other side to upgrade to TLS. We currently assume Syslog has a IANA allocated port for tls transport mapping, we may not need such complexity on upgrading. FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to this draft, RFC2817(Informational) is on upgrading. We clearly stated in our charter that we won't define a plain TCP version (although I personally disagree). I think that we have discussed this before; you are free to write your own ID on this. I know that others support this so you should be able to find people to help. A simple capability negotiation can be useful for reasons beyond TLS upgrade, like an optional support for Application Layer acknowledgements. I fear that if we start going down that path we will reinvent RFC 3195. We need to continue addressing simplex syslog with syslog-transport-tls. We can address capabilities exchange either in 3195bis or it can be looked into in a future revision of syslog/tls (yet another good reason for a version field). If you get a lot of people doing syslog/tcp with a capabilities exchange mechanism then it should be simple to put that into a subsequent version of syslog-transport-tls. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Legitimate \n or byte-counting
Hi, 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. We need this answered today. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RE: byte-counting vs special character
Hi, On Thu, 17 Aug 2006, Balazs Scheidler wrote: On Wed, 2006-08-16 at 12:32 -0700, Carson Gaspar wrote: 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. As I said in a private mail to you, no we don't need that switch. LF is escaped as a sequence of two characters '\' and 'n'. This way escaped LF characters will not affect protocol processing, the only issue is that LFs in the message will be written to the disk in a slightly different format. But adding the fact that current TCP senders are not transparent wrt LFs this is not a big deal. - old sender - new receiver = works, because current syslog-TCP senders strip LFs off the message, either they replace it with space or forward multiple messages - new sender - old receiver = works, because the old receiver does not care about the \n string in the message, although it will not unescape it when it writes it to disk What's going to happen with syslog-sign and/or other mechanisms that will look at the packet and create a hash of it? It sounds like everything will be acceptable if a new receiver gets it and does the re-conversion before anything looks at the contents. However, an old receiver will continue to keep the \n which will mess up syslog-sign. Is that correct? Also, what's going to happen to a new receiver that receives a legitimate \n as in an original message send: PRI... BOM The offending characters are \n Will the receiver convert that into LF? Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] RE: byte-counting vs special character
Hi, I agree; we don't want a vote here. We want strong technical reasons for making a decision. Thanks, Chris On Wed, 16 Aug 2006, David Harrington wrote: Hi Rainer, The IETF doesn't vote. The chairs will determine consensus on or after the Aug 18 deadline for this decision. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 16, 2006 8:08 PM To: Carson Gaspar Cc: [EMAIL PROTECTED] Subject: 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 ___ 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-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 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] Consensus on the Huawei IPR claim
Hi Folks, The consensus reached is that: The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. There were numerous votes cast for this option. Most were public and are in the archive and I recieved two additional private responses for this. I saw very few votes for not continuing with this document on the list, and I received none privately. I want to thank everyone for taking the time to consider the IETF position on IPR, and for reviewing the Huawei terms. I also want to thank David Harrington for his professional attitude. There are no rules in the IETF saying that he had to recuse himself from this discussion, but I know that he felt that the discussion would proceed more smoothly if he did. And last, I want to thank Huawei for following the process on claiming IPR. I will mention one more time that the IETF, and our Working Group cannot and will not make any determination on the validity of any IPR claims. And with that... Let's get back to work. :-) We have a short timeframe to finish syslog-transport-tls and get it to the IESG. Please get your comments in to the mailing list and let's move this forward. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
REMINDER - voting still open until July 19 - Re: [Syslog] Need your input on the Huawei IPR claim
Hi Folks, Please continue to send in your opinion on this. I'll determine consensus next Thursday and outline our steps to go forward. Thanks, Chris On Wed, 5 Jul 2006, Chris Lonvick wrote: Hi Folks, Everyone has now had a week to think about the IETF process on IPR claims. The first decision that we need to make is about the terms of the claim. I'd like to hear what people think about the terms that Huawei has presented. https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=724 Please keep in mind that we can (and should) proceed with syslog-transport-tls if the terms appear reasonable and you (as implementors) are willing to accept them. Let's keep this discussion focused. - We do not need a discussion of the terms. - We do not need any legal opinions. - We do not need a discussion of technical alternatives on this thread. From that, I'd like to hear either: A) The WG SHOULD proceed with draft-ietf-syslog-transport-tls as a Working Group document. or B) The WG SHOULD NOT proceed with draft-ietf-syslog-transport-tls as a Working Group document. I'll leave this open until the 19th (so people going to the IETF can catch their collective breaths and give a good opinion. If the consensus appears to be A then we can get straight back to work. If the consensus appears to be B then I will very briefly ask if there are changes to the terms that would make them acceptable. I'll only ask that if the consensus appears to be B so don't insert your opinions on that at this time. I'm (just barely) willing to ask that (once) of the Huawei lawyers but I feel that negotiating terms is not going to move us forward; it's likely to be a rat-hole discussion and I won't let us go down there. If the consensus remains B then we will likely move away from syslog-transport-tls. Where we move to will be a different discussion so please don't insert your opinion about that on this discussion thread. David has opened that discussion on a separate thread so you may discuss it on the list, but I'm not focused on that at this time. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Payload stuff is out of scope for our WG
Hi, I've seen a lot of discussion about payload format on the list lately. I think that everyone already knows the charter of the WG but I want to be clear about this; we're not going to address that issue within our WG. I'm OK with having some discussion around this as it makes us think about the header information that we've defined in syslog-protocol. However, we are not going to define the payload format in our Working Group. I would encourage everyone interested in this topic to follow David's advice and get involved with the discussions going on in the Operations and Management area of the IETF and in other Standards Developing Organizations. For the IETF, please take a look at the latest IESG retreat notes here: http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt See section 11. Similarly, it might be good for interested people to hold a BoF at IETF 67 (San Diego in November). Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Having IPR in IETF Documents
Hi Rainer, On Sat, 10 Jun 2006, Rainer Gerhards wrote: 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. Right. We don't know what Hauwei is claiming, or even if they discovered something in this document. BCP 79 is more clear than I was, there might be something in the document that was discovered before the authors started writing. 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. Again, let's please be patient. Hauwei is new to the IETF and, as it's been pointed out on the list already, they are new in the patent filing system. Let's follow the process and see what works out. 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. Please do. I will convey information as it happens. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Call for David Harrington to resign from syslog as co-chair
Hi Darren, David has recused himself from this discussion because of any possible conflict of interest. As you note, the claim statement does not accurately reflect the sections of the ID, but rather the sections of the claim statement itself. I am working on getting more information about the claim and then we can see what the Working Group wants to do. For now, I will ask for some patience from everyone while we sort this out. Thanks, Chris On Sat, 10 Jun 2006, Darren Reed wrote: As someone who works fr the offending company, I might point out that the lodged IPR statement does not accurately reference the draft at all. It talks about section IV and section V. The current draft has no section IV or section V. The draft does have sections labelled section 4 and section 5. If you know anything of legal documents and messages then you will understand that they need to be accurate. Ask your lawyer for more information on this. Given your role as chair and that you are employed by the company involved, I would like to ask you to resign your role as co-chair here because I believe your commercial interests are compromising the direction and role of this group. If you do not wish to voluntarily resign I will ask the group to take a vote on this matter. As it stands, there are a number of people who do not like this move and I can imagine any number of them would feel betrayed by it. Darren Hi, As co-chair it is my responsibility to make the WG aware that there has been a disclosure that an unpublished pending patent application might be infringed by the implementation of the specifications in draft-ietf-syslog-transport-tls-01.txt. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=717. 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
separate - Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
Hi Sam, Please keep this between us for the moment. On Thu, 8 Jun 2006, Sam Hartman wrote: First, have you looked at the updated IPR disclosure? Yes. The Cisco lawyer who deals with IPR says that he is confused by it. He suggests that I ask for a clarification of what is based on royalty-free with other reasonable non-discriminations terms and conditions. There are other spelling and grammar problems as well. I figure that if my lawyer is confused by it, I can't ask the WG to go along with it. David says that Huawei wants the license to be easy and painless. I'll attempt to get consensus on that. Right now, some people who have been implementing are a bit hurt thinking that Huawei is claiming everything. I figure that there is a claim, or some claims, in the document and that Huawei is not attempting to cover the entire concept of syslog/tls. However, that is not clear from the disclosure so I'm getting some problems in the WG. If there are specific claims and it comes to light then I may be able to get some more acceptance of the terms. Any advice would be appreciated. You can work on udp and -protocol, and you can even update your milestones to reflect that. You can get as far as sending me a publication request for these documents. However I will not take the documents to the IESG without a security solution. So, I'll wait until it seems clear that there will be WG consensus to actually publish the TLS draft (or something else of your choosing) before I bring -protocol to the IESG. OK. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: separate - Re: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
Hi, OK - I blew it. My apologies to the Working Group and to David for my obvious problem. I had meant that to be an update to Sam only. With sincere apologies, Chris On Fri, 9 Jun 2006, Chris Lonvick wrote: Hi Sam, Please keep this between us for the moment. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Having IPR in IETF Documents
Hi Folks, 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. This is not unique to our Working Group. Please look at the other IPR disclosure statements that have been filed: https://datatracker.ietf.org/public/ipr_list.cgi I also want to note here that Hauwei has done the right thing in filing a disclosure. Please consider what would happen if a company knowingly inserted IPR into a standard without disclosing it. People and companies would implement it and would then be liable for whatever terms were imposed upon them. RFC 3979 clearly states that a disclosure must be made, and Huawei has done that. The IETF will not make any assertions about the validity of any claim. RFC 3979 is clear on this point as well. As a Working Group, we have been informed that some IPR has been claimed and we will need to deal with it without attempting to decide if it is a valid claim or not. Now that we know that IPR is being claimed in one of our documents, we have some options open to us. We can either accept the terms and continue with the document, or we can attempt to work around the claim. There is a process here and we will follow it. I am again asking for your patience while we sort some things out. When we have more information, I will start asking for consensus on the mailing list. The first thing is to ask Hauwei to update their disclosure to address the most recent version of the document. I've sent that request and will notify everyone when I get a response. What David Harrington has done has also been proper and according to form. He has notified the Working Group of an IPR disclosure statement. He called me and we discussed the situation. He felt that he didn't want there to be any question of a conflict of interest between his position as WG Co-Chair and that of a Huawei employee in this matter so he has recused himself of this discussion. I will ask for your coorporation and support in following this process so we can reach consensus and move forward. If you wish to debate the use of IPR in IETF documents, please go to the iprwg. http://www.ietf.org/html.charters/ipr-charter.html Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Re: Why are we doing netconf? (fwd)
Hi Folks, I think that this resolves the netconf discussion. Thanks, Chris -- Forwarded message -- Date: Wed, 29 Mar 2006 14:53:20 -0800 From: Andy Bierman [EMAIL PROTECTED] To: Sharon Chisholm [EMAIL PROTECTED] Cc: Netconf (E-mail) netconf@ops.ietf.org Subject: Re: Why are we doing netconf? Sharon Chisholm wrote: hi To all the people who want netconf to be a replacement for syslog, snmp, ipfix, or whatever: How about if we solve network configuration first, then replace every other MGMT protocol in the world with our new protocol? (!) I don't think the WG agrees that notifications in the NETCONF protocol is a critical missing component, let alone the most important critical missing component. For NETCONF to be truly content-independent, the notification delivery mechanism needs to be totally decoupled from notification content. There are a lot of different ideas on this content, and who should standardize it. I am totally opposed to the NETCONF WG working on syslog content. We need syslog experts (and the Chair) for that. Sounds like a BOF in the works, but no NETCONF work item here. I am also totally opposed to working on anything but the bare minimum number of standard notifications (like config-change) at this time. You want a data model, how about creating a writable interfaces table and an access control model? These are critical missing data models. Andy Thanks Dave for the well-thought through post. I think the 'restriction' on Netconf for configuration has always been an artificial one, but it has served us well. One of the big problems we ran into with SNMP was we kept picking off the easier problem of monitoring and never giving configuration enough focus. By limiting the focusing primarily on configuration for Netconf 1.0, we have ended up with a great technical solution that is seeing some good market uptake. I think actual implementations of Netconf are not limiting themselves to just configuration. The CLI never did. For deployments, the high cost of having to integrate information from different sources gets weighed against the cost of having to replace legacy systems. Sometimes it wins. Sometimes it doesn't. For the most part, all this can be done using the existing framework. The gaps that people run into when trying to do this are, I believe, the same ones they run into while trying to use Netconf for configuration - access control, data model and notifications. Another gap might be 'operational' commands such as rebooting and maintenance, but the universal requirements there are not yet clear to me. I've personally been working both the data modeling and the notification issue. I'd work access control, but other then a sense that I'd like something simpler then we've seen in the past, I have no idea what we would need. They are all important, both for configuration-only implementations and configuration-plus ones. I've focused more on the notification work lately because I was getting a lot of pushback on the data model work from certain people, but I'm willing to put time on that topic again. I think though, that for people looking to be able to pick up third-party Netconf stacks, there are some big advantages to being able to standardize on any extended protocol operations sooner rather then later. As far as whether if we said from day one that netconf would do more than configuration and things would have been designed differently, I don't now if that is the case. As far as being forced to solve problems at some point in the future related to performance management if we don't somehow engineer/re-engineer the protocol so it can't be used for things like that, I don't think that would be helpful. At that day in the future the community can decide whether it wants to spend time on that particular problem. Plus, unless at that point in the future we learned that they were not also using Netconf for configuration, this would be a sign of success. So, in summary, I think the current notification work absolutely is necessary for configuration management. I don't see the value of precluding its use for other functions and I believe for the other functions all we need to do is provide the ability to specify the correct event class. I'm also willing to work on the other gaps. Sharon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harrington Sent: Tuesday, March 28, 2006 1:26 PM To: 'Netconf (E-mail)' Subject: Why are we doing netconf? Hi, I would like a better understasnding of why we are doing notifications. I am struck by what appears to me to be two very different drivers for netconf, and the why are we doing notifications? question relates to these different motivations. I have suggested that the OM and Security communities should work at establishing a strategic vision about converging aspects of the various NM protocols and NM
[Syslog] [logs] computerworld article: Making the case for an audit standard (fwd)
Hi, Just FYI - The article is about the US NIST's effort to standardize event message formats. The link to the NIST workshop is: http://csrc.nist.gov/CLIX/ Thanks, Chris -- Forwarded message -- Date: Wed, 15 Mar 2006 10:40:37 -0800 From: Jian Zhen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [logs] computerworld article: Making the case for an audit standard An interesting article by Oracle's CSO on audit and logging standard. http://www.computerworld.com/printthis/2006/0,4814,109554,00.html just an FYI ___ LogAnalysis mailing list [EMAIL PROTECTED] http://lists.shmoo.com/mailman/listinfo/loganalysis ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Coming to consensus on syslog threats
Hi Miao and Yuzhi, As Tom Petch pointed out we do need to establish that a TLS transport will address the threats we have described. Would you briefly outline how you propose to utilize TLS to address Modification, Disclosure, Masquerading? (Others can jump in here with more comments and concerns so the document can get a good start.) Once we establish that I believe we can accept your offer to write the document. Many thanks, Chris On Wed, 8 Feb 2006, Miao Fuyou wrote: I and Yuzhi would like to edit a draft on syslog tls transport. We will get the draft posted ASAP. Miao [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Tuesday, February 07, 2006 10:10 PM To: [EMAIL PROTECTED] Subject: [Syslog] Coming to consensus on syslog threats Hi, In reviewing the messages around the threats to the syslog protocol, it appears that the priority of threats is as follows: Primary: Modification Disclosure Masquerading Secondary: Message stream modification Not highly considered: DoS Traffic Analysis Disclosure has been controversial in the discussions. It has been noted that syslog messages are freeform text and the possibility of sending sensitive information will always exist. This is all the more true if high levels of debugging are enabled. Also from the list, it appears that the use of TLS is supported and will address these threats. I will ask for volunteers to write syslog-protocol-tls and get it through the process. It looks like syslog-protocol and syslog-transport-udp are very close to being finished. I'd like to wrap those up and fully concentrate on syslog-transport-tls, syslog-sign, and syslog-device-mib. syslog-transport-tls will have to go through the process at the same time as syslog-protocol and syslog-transport-udp. I'll ask Rainer and Anton to please be patient while we complete this final document. With that, I'll propose the following Charter revision and Milestones. ---vvv--- Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. 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. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. 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. The secondary threat of message stream modification can be addressed by a mechanism that will verify the end-to-end integrity and sequence of messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized
Re: [Syslog] Coming to consensus on syslog threats
Hi Tom, You are correct. I'll change that to: Nov 2006 Submit a secure syslog transport mapping document to the IESG for consideration as a PROPOSED STANDARD. Thanks, Chris On Thu, 9 Feb 2006, Tom Petch wrote: Chris I notice that the body of the proposal takes a neutral stance towards which secure transport but then specifies TLS in the milestones. I suggest that you keep the milestones neutral as well, not because I expect any different but because I think it more acceptable to those that will review it. Tom Petch ---remainder deleted for brevity--- ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Threat model requirements discussion
Hi Folks, We need to back up a moment and formalize our thoughts on the threats that we are going to address to secure syslog messages. We need to have this discussion to ensure that any mechanism we decide to provide will address the threats. The summary of our discussion will likely be included in syslog-transport-(secure) to show our objective and how the mechanism meets it. From the prior discussions, it looks like the primary threats to current syslog messages are: - message observation - message tampering, injection, replay - message loss If these are the threats (please respond to the list if you don't agree), then we can deploy the following mechanisms to thwart them: - message encryption at the transport layer will prevent observation - transport layer encryption with a sufficient message authentication check (mac) mechanism will allow a receiver to detect attemps of tampering, injection and replay - transport layer encryption will provide seqenced delivery of messages in transit Is this sufficient for our needs? Does the possibility of message loss due to network unavailability need to be addressed at this time? This will be addressed in syslog-sign, but do we need an additional mechanism (such as the required use of the eventID SD-ID) to ensure that messages generated but not delivered are detected by the receiver? If we can agree that these are the threats, and mechanisms that will thwart them, then we can finalize our discussion on a transport layer service and add that to our charter. Please respond to the list with your thoughts. We need responses to this to make sure that we're on the right track with this discussion. Please keep Sam cc'd on this thread. Thanks, Chris ___ 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. 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? 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. 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: [Syslog] Re: Threat model and charter
Hi Sam, I also have a concern that we may try to craft an answer that provides good security but that won't actually be deployed. As an analogy, snmp has similar characteristics to syslog. usm has good security properties but has not been widely deployed. isms is trying to redress that and is also getting bogged down in transport issues. RFC 3562 (Key Management Considerations for the TCP MD5 Signature Option) indicates that shared secrets don't get deployed unless there is a real threat. Even then, it takes a lot of effort to maintain those credentials across a very large network. Utilizing X.509 credentials has much better security properties but are the operations groups of large networks going to be willing to implement that? I would like to hear more discussion from developers, operators and network managers before we draw conclusions. Thanks, Chris On Wed, 11 Jan 2006, Sam Hartman wrote: I'm concerned that your analysis seems to be based on what is easy to implement. 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. 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. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
Hi, I was thinking that if we have to do authentication then we could try to get consensus on a simple authentication mechanism - a shared secret. Essentially, each sender would have to be configured with a shared secret before it could use TLS. The receivers and relays would also have that information. When a sender prepares a message, it would hash the shared secret with the formed message. That hash could be placed in an SD element ( [tlsAuthChk=12345678...] ). The recipient could extract the value, and then re-run the hash. If the received hash is the same as the calculated hash then both the sender and the receiver must be using the same shared secret. The caveat to this is in choosing the right hash algorithm. This mechanism and shared secret authentication has been well defined in many prior RFCs. A lot of those RFCs used MD5 which is now going out of favor. Check out RFC 1305 (NTP - appendix D) and RFC 2385 (authentication for BGP). This suggestion tries to keep the ease-of-use of syslog. Using credentials stored in an X.505 certificate (of the recipient) would provide a higher degree of authentication - shared secrets can be much more easily compromised (found, guessed, brute-forced, etc.) than the validated credentials contained in a certificate. If we can get consensus that an in-packet authentication mechanism like this is sufficient to meet our threat model, then we can decide if the shared secret is sufficient (the REQUIRED mechanism), and/or if we want to RECOMMEND a similar X.509 mechanism. That would require having each syslog sender to have an X.509 certificate, and have those signed and available. That just seems to me to be getting a bit far away from the ease-of-use that makes syslog so easy to deploy. Thoughts? Thanks, Chris On Wed, 11 Jan 2006, Balazs Scheidler wrote: On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: Chris, However, it *is* possible to authenticate the peers via X.509 certificates. Any TLS implementation can do client and server certificate verification as part of the session setup process. To the best of my knowledge, some folks use this feature with stunnel. So the server accepts messages only from clients which are authenticated via their certificate (their certificate-based names are configured at the server side). I basically agree with you, one minor addition that this X.509 certificate based authentication is a hop-by-hop authentication and provided the operator trusts all devices on the message path and requires authentication on each hop, then message authenticity can be ensured. There's no per-message signature, thus it is not proovable that a message was generated by a given device after it has been received and stored. A parallel example: It is in a sense similar to client authentication in HTTPS: if you upload a file using HTTPS where client certificate was required and validated, then the file on the server can be trusted to a certain extent (as much as the HTTPS server can be trusted), however there's no means to prove that the file has not been tampered with after it has been received. There was no signature _stored_ along the file and no such signature exists in the HTTPS protocol itself, to do this the HTTPS client would need to generate a signature before transmission and upload the signature along with the file itself. Back to syslog: TLS and X.509 certificate authentication is hop-by-hop and authenticates the infrastructure and network transmission (like HTTPS itself), syslog-sign is a per-message authentication similar to the client-side-sign-and-upload-along-with-file example in HTTPS as described above. -- 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
SSH - RE: [Syslog] Re: Threat model and charter
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? Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Re: Threat model and charter
Hi Working Group, I'll pass this along to those people who have already implemented syslog/TLS(SSL). Please be specific about why you did this. Thanks, Chris On Tue, 10 Jan 2006, Sam Hartman wrote: Hi. Can you explain what actions on a part of an attacker are prevented in terms of attacks on message integrity without authenticating the source of the message? In general, the security community is very suspicious of mechanisms that provide integrity without authentication. If you are going to propose such a mechanism then you need to explain why it is appropriate in your environment. In effect, in terms of integrity, it sounds like you say that it is important for a sender to know that the message has been transported to the receiver unmodified. However since the receiver does not know who is sending it the message, the receiver cannot know anything about the integrity of the message. It may be a bit more complicated than that. If the message contains confidential information that an attacker could not have generated then the receiver may actually know that the message is unmodified without knowing who generated it. However it seems like your proposal does not protect against a number of attacks. In particular, an attacker can generate messages appearing to come from any source and containing content of the attacker's choosing. This combined with the ability to suppress messages sounds like enough to get around any message integrity you might have. Also, I'd reword the charter bullet regarding the secure transport. You want a bullet claiming that you will write a document describing a secure transport. Actually requiring the secure transport be implemented happens in the protocol document. As a result, you cannot submit syslog-protocol to the IESG until this transport document is written. It might be possible for the protocol document not to discuss mandatory transports at all and for there to be a later applicability statement for syslog requiring protocol, the secure transport and UDP. RFC 2026 does allow that structure but I don't know of any WG who has actually done things that way. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
Hi Sam, On Thu, 5 Jan 2006, Sam Hartman wrote: 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 Is Section 8 in draft-ietf-syslog-protocol-16.txt sufficient? Alternatively, Section 6 in RFC 3164 is fairly comprehensive. 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. RFC 3195 requires the use of RFC 3080 which requires TLS. 2) Require that all senders implement signatures stored in structured data as an option. That's likely addressed through syslog-sign. 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. The questions for you: - Do we need to produce a threat model in a new document? - Can we state that the threats will be addresses in syslog-sign and 3195bis? I will also note that there is a group of implementors who have already done syslog/tls. I suspect they would like to codify this in a standard and that may also address the threats. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] I-D ACTION:draft-ietf-syslog-protocol-16.txt (fwd)
Hi Folks, This is it. We need people to review this and get back to the WG. When you reivew it, either send in notes about issues, or respond by saying that you have reviewed it. (We DO need me too's.) Thanks, Chris -- Forwarded message -- Date: Tue, 03 Jan 2006 15:50:02 -0500 From: [EMAIL PROTECTED] To: i-d-announce@ietf.org Cc: [EMAIL PROTECTED] Subject: I-D ACTION:draft-ietf-syslog-protocol-16.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename: draft-ietf-syslog-protocol-16.txt Pages : 45 Date: 2006-1-3 This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the spirit of traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. The layered architecture also provides a solid basis that allows code to be written once instead of multiple times, once for each syslog feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-16.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-syslog-protocol-16.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-syslog-protocol-16.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Me too and our Timeline
Hi All, The WG does need Me too. comments to show consensus. If I don't see those on the list then the issue will be dropped. We do not have the time for lengthy discussions on any topic dealing with syslog-protocol and syslog-transport-udp. If anyone brings up a topic, they really need to supply appropriate text so Rainer and Anton can get on with writing the drafts. Thanks, Chris On Thu, 15 Dec 2005, Darren Reed wrote: Darren, I have seen nobody backing your position, so I think it was consensus to ignore these comments. And nobody decrying them either. So are you saying, you need me too's on comments before you'll make any replies to issues people bring up ? It shouldn't take everyone to speak out about an issue for it to be valid, it should only take one. If 5 people came back with 5 different issues each, would you ignore all 25 because none of them brought up the same one ? This is meant to be the value in peer revue and if you start ignoring comments that only get brought up once, you're undermining the efforts and effectiveness of this group. Darren ___ 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] Newly revised proposed charter
Hi All, Sam has asked that we nail down one topic in our re-chartering effort: backwards compatibility. I'll propose the following modification to our Charter and I've also put in some Milestone dates below. === Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. 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 RPI at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Milestones: Mar 2006 Submit Syslog Protocol to IESG for consideration as a PROPOSED STANDARD Mar 2006 Submit Syslog UDP Transport Mapping to IESG for consideration as a PROPOSED STANDARD. Jul 2006 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Jul 2006 Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD. === Thoughts and comments please. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] MSG encoding and content (#3, #4, #5) (fwd)
Hi Rainer, I don't believe that we need to follow up with Patrik immediately. It looks like we have some general consensus on the charset issue. Please update the ID with the consensus points that we have reached at this time. Thanks, Chris On Thu, 8 Dec 2005, Rainer Gerhards wrote: Chris, I can agree to what you propose. So it's fine with me. Question: does it make any sense to answer some of Patrik's questions (in order to obtain some more advise). I guess he is pretty busy, so we might save this for later. I'd appreciate your advise. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Wednesday, December 07, 2005 8:11 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Hi Folks, I asked Patrik Faltstrom to review this proposal. He has some comments below. Let's don't get hung up in his details - he has looked this over without any knowledge of our prior discussions. He does have some good pointers. We may want to consider a belt and suspenders approach. - senders MAY indicate their charset in the SD-ID. If the SD-ID does not contain any indication of a charset, then the receiver will just have to guess (it may be US-ASCII or it may be something entirely different). Having the UTF-8 BOM there would be a good indication that it is UTF-8. - senders are RECOMMENDED to include a charset indicator in the SD-ID. The ONLY one defined in the syslog-protocol will be [charset=UTF-8]. When that is specified, then the BOM MUST be present. To address Bazsi's concerns of too many charset definitions, Rainer could indicated that additional charset values can only be accepted by the IANA through Standards Action (RFC 2434). As Patrik indicates, it would be good to see this separated into - what can the sender send - what will the receiver expect to receive. I would like to see other comments on this proposal. I need to review the threads but I believe that we have rough consensus on all of the other issues so that Rainer can re-work syslog-protocol. Thanks, Chris PAF's comments below -- Forwarded message -- Date: Wed, 7 Dec 2005 17:23:24 +0100 From: [ISO-8859-1] Patrik Fältström To: Chris Lonvick [EMAIL PROTECTED] Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Let's first quickly review what has been discussed on list: - current implementations sometimes use LF as a record delimiter Ok - some implementations use LF inside the MSG part Ok - some implementations include binary data in syslog messages and would like to continue to do so (but these seem to be few) Ok - there are at least some use cases where a syslogd can not definitely detect the character encoding of a message (some of that might be related to the POSIX API, but there may be a work-around [I had no time yet to evaluate this in-depth]). It gets problematic if a message from a legacy sender is received (no encoding information) and transformed into a syslog-protocol message [I assume this is a valid use-case]) Ok - previous discussion showed the need for Unicode. With Unicode, the term printable character basically becomes useless, because there are so many non-printable characters in Unicode and new ones are potentially added constantly. Well...define printable... I don't really know what that means. - previous consensus thus was that any valid UTF-8 string MUST be supported inside MSG (including NUL and LF) NULL and LF are part of Unicode, and because of that UTF-8. The encoding UTF-8 encode NUL and LF as one byte only, with the same value as LF and NUL as we are used to. - current discussion has shown that backwards-compatibility is not absolutely vital (but still desirable) Ok. Solves some of the binary problems. - it was suggested that an encoding SD-ID be defined which carries the character set definition Hmmmwhy is the charset definition needed? That is then to be able to say UTF-8 or BIG5 or...? It seems to be better and more important to say whether it is UTF-8 or for example binhex encoded binary data. Remember that the main difference between text and binary is that text is to be converted regarding linebreak algorithms, while binary data is not. - as a side-note, Tom Petch has provided a very good digression on character encoding terminology which I have reproduced after my signature. I guess most people on this list already know the exact differences, but I still find it useful... Ok. Can not remember I have seen it, but anyway... It is somewhat hard to find a good compromise. A compromise, in my point of view, must allow the following: When looking at a protocol like this, you have to first of all define whether the charset translation/transformation is happening in the client or in the server. This is not really clear to me. If the transformation is in the client, the client translate
[Syslog] Re: Terminator
Hi Tom and All, We have made great progress on Rainer's list of issues. I believe that they are all resolved to the point that Rainer can issue a new draft for review. I would like some additional discussion on this point. If I don't see some rough consensus on this by the time Rainer posts his next draft then I will push this off of the table and it can be resolved in version 2. Thanks, Chris On Fri, 9 Dec 2005, Tom Petch wrote: As RFC like 2130 state, protocol designers should differentiate between protocol - which does not have language, charset etc - and text, which has. I see the text elements of syslog as MSG and PARAM-VALUE; these are the ones defined as UTF-8-STRING and so the ones to which these issues apply. The problem for me is termination of the string so that for the latter, syslog-protocol says characters '', '\' and; ']' MUST be escaped so these can then be used to tell us where the PARAM-VALUE ends. In essence, we are defining a transfer syntax for this these fields (not IMHO a very elegant one but I don't have a better idea - I note that syslog-sign uses base64 to transfer encode its binary). So how do we terminate MSG? Using a count has been suggested, ASCII NUL is obviously used in some implementations; elsewhere I assume that it is determined implicitly by the length of the UDP packet. I believe this is not enough, since TCP is around as a transport and should be on our radar. Allowing UTF-8 as the charset (IETF's preferred term for CCS+CES) allows all octet values from +0 to +127 and most of +128 to +255 so we lose the obvious terminating characters. MIME either uses a transfer syntax such as base64 or quoted printable - which brings many values back into play - or allows the generating software to create its own terminating string which can then be chosen not to appear in the free text. NETCONF uses a string that can never be valid XML in a similar manner. My instinct is we should be doing more in this area, in particular having greater consistency between MSG and PARAM-VALUE, in their transfer syntax and termination.. Anyone else agree or disagree? Tom Petch - Original Message - From: Chris Lonvick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 8:10 PM Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Hi Folks, I asked Patrik Faltstrom to review this proposal. He has some comments below. Let's don't get hung up in his details - he has looked this over without any knowledge of our prior discussions. He does have some good pointers. We may want to consider a belt and suspenders approach. - senders MAY indicate their charset in the SD-ID. If the SD-ID does not contain any indication of a charset, then the receiver will just have to guess (it may be US-ASCII or it may be something entirely different). Having the UTF-8 BOM there would be a good indication that it is UTF-8. - senders are RECOMMENDED to include a charset indicator in the SD-ID. The ONLY one defined in the syslog-protocol will be [charset=UTF-8]. When that is specified, then the BOM MUST be present. To address Bazsi's concerns of too many charset definitions, Rainer could indicated that additional charset values can only be accepted by the IANA through Standards Action (RFC 2434). As Patrik indicates, it would be good to see this separated into - what can the sender send - what will the receiver expect to receive. I would like to see other comments on this proposal. I need to review the threads but I believe that we have rough consensus on all of the other issues so that Rainer can re-work syslog-protocol. Thanks, Chris PAF's comments below -- Forwarded message -- Date: Wed, 7 Dec 2005 17:23:24 +0100 From: [ISO-8859-1] Patrik Fältström To: Chris Lonvick [EMAIL PROTECTED] Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Let's first quickly review what has been discussed on list: - current implementations sometimes use LF as a record delimiter Ok - some implementations use LF inside the MSG part Ok - some implementations include binary data in syslog messages and would like to continue to do so (but these seem to be few) Ok - there are at least some use cases where a syslogd can not definitely detect the character encoding of a message (some of that might be related to the POSIX API, but there may be a work-around [I had no time yet to evaluate this in-depth]). It gets problematic if a message from a legacy sender is received (no encoding information) and transformed into a syslog-protocol message [I assume this is a valid use-case]) Ok - previous discussion showed the need for Unicode. With Unicode, the term printable character basically becomes useless, because there are so many non-printable characters in Unicode and new ones are potentially added constantly. Well...define printable... I don't really know what that means. - previous
Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd)
Hi Folks, I asked Patrik Faltstrom to review this proposal. He has some comments below. Let's don't get hung up in his details - he has looked this over without any knowledge of our prior discussions. He does have some good pointers. We may want to consider a belt and suspenders approach. - senders MAY indicate their charset in the SD-ID. If the SD-ID does not contain any indication of a charset, then the receiver will just have to guess (it may be US-ASCII or it may be something entirely different). Having the UTF-8 BOM there would be a good indication that it is UTF-8. - senders are RECOMMENDED to include a charset indicator in the SD-ID. The ONLY one defined in the syslog-protocol will be [charset=UTF-8]. When that is specified, then the BOM MUST be present. To address Bazsi's concerns of too many charset definitions, Rainer could indicated that additional charset values can only be accepted by the IANA through Standards Action (RFC 2434). As Patrik indicates, it would be good to see this separated into - what can the sender send - what will the receiver expect to receive. I would like to see other comments on this proposal. I need to review the threads but I believe that we have rough consensus on all of the other issues so that Rainer can re-work syslog-protocol. Thanks, Chris PAF's comments below -- Forwarded message -- Date: Wed, 7 Dec 2005 17:23:24 +0100 From: [ISO-8859-1] Patrik F?ltstr?m To: Chris Lonvick [EMAIL PROTECTED] Subject: Re: [Syslog] MSG encoding and content (#3, #4, #5) (fwd) Let's first quickly review what has been discussed on list: - current implementations sometimes use LF as a record delimiter Ok - some implementations use LF inside the MSG part Ok - some implementations include binary data in syslog messages and would like to continue to do so (but these seem to be few) Ok - there are at least some use cases where a syslogd can not definitely detect the character encoding of a message (some of that might be related to the POSIX API, but there may be a work-around [I had no time yet to evaluate this in-depth]). It gets problematic if a message from a legacy sender is received (no encoding information) and transformed into a syslog-protocol message [I assume this is a valid use-case]) Ok - previous discussion showed the need for Unicode. With Unicode, the term printable character basically becomes useless, because there are so many non-printable characters in Unicode and new ones are potentially added constantly. Well...define printable... I don't really know what that means. - previous consensus thus was that any valid UTF-8 string MUST be supported inside MSG (including NUL and LF) NULL and LF are part of Unicode, and because of that UTF-8. The encoding UTF-8 encode NUL and LF as one byte only, with the same value as LF and NUL as we are used to. - current discussion has shown that backwards-compatibility is not absolutely vital (but still desirable) Ok. Solves some of the binary problems. - it was suggested that an encoding SD-ID be defined which carries the character set definition Hmmmwhy is the charset definition needed? That is then to be able to say UTF-8 or BIG5 or...? It seems to be better and more important to say whether it is UTF-8 or for example binhex encoded binary data. Remember that the main difference between text and binary is that text is to be converted regarding linebreak algorithms, while binary data is not. - as a side-note, Tom Petch has provided a very good digression on character encoding terminology which I have reproduced after my signature. I guess most people on this list already know the exact differences, but I still find it useful... Ok. Can not remember I have seen it, but anyway... It is somewhat hard to find a good compromise. A compromise, in my point of view, must allow the following: When looking at a protocol like this, you have to first of all define whether the charset translation/transformation is happening in the client or in the server. This is not really clear to me. If the transformation is in the client, the client translate to for example UTF-8. It can also be the server doing it. (Or of course a client that read from wherever the syslog daemon store the data, so that the storage can handle multiple charsets...but I think this is out of the question?) - transforming existing messages into -protocol format should not intentionally be forbidden - transformation is a very important feature when it comes to deploying new technology Yup. - new receivers should be able to precisely enough understand the message content Ok. Message content from old senders? - I also find it advisable that newer receivers are capable to process both old-style and new-style messages concurrently. While this is an implementation issue, it might be a hint for us that some subleties
RE: [Syslog] #2, max message size - Need to resolve this
Hi Rainer, You're the document author - you decide. I'm the WG Chair and my job is to make sure that the work continues. I think that we all would like for the document to be crisp, clear and to the point. Thanks, Chris On Thu, 1 Dec 2005, Rainer Gerhards wrote: Chris, Wouldn't David's text be suitable? I think it is very clear and precise. With it, probably the whole issue hadn't started. I know this WG likes it very brief, but isn't it worth the extra lines? Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Thursday, December 01, 2005 8:36 PM To: David B Harrington Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] #2, max message size - Need to resolve this Hi David, On Thu, 1 Dec 2005, David B Harrington wrote: Hi Chris, You have framed the question incorrectly. That became evident when people started responding. :) It appears that we have consensus that: - Rainer will place a recommendation of lengths into syslog-protocol so that recievers will have some expectations and, - transport documents will contain a not-to-exceed length requirement. Thanks, Chris This discussion is about the minimum maximum message length, not the maximum message length. This is about at least this big and not about no bigger than. All receivers MUST be able to handle the minimum maximum message size X, and it is RECOMMENDED that all receivers be able to handle messages of size Y, and receivers MAY choose to support sizes larger than Y. Senders can rest assured that any standard-compliant receiver WILL be able to handle messages of size X, so the sender can send a message of that size or less and not worry about it being truncated or dropped (so if it is a critical message, keep the message shorter than X). Senders can rest assured that most, but not all, compliant receivers WILL be able to handle messages of size Y, but there is a chance of the message being truncated or dropped, so if the message is important but you can live with it being dropped, then keep the message shorter than Y, and it will usually work. Senders can try to send messages larger than Y, but many receivers will be unable to handle such a size. Transport mappings may apply different constraints, but regardless of the transport, a compliant implementation MUST support the transport-independent limit X, and it is RECOMMENDED that the transport-independent limit Y be supported for improved interoperability. If desired an implemntation MAY allow larger sizes. Writers of transport mappings should pay attention to these limits. All transport mappings MUST support at least size X. If the transport can support size Y, then the transport mapping contraint should be set to no less than size Y, and for consistency with the transport-independent recommendation, SHOULD RECOMMEND support for size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If a transport mapping can handle sizes larger than Y, then the transport mapping can support larger messages, and MAY choose to set transport-specific contraints larger than Y. Is this strictly about which transport mapping is used? No, it is not! It establishes some standards that should be followed regardless of the transport used, if possible - all implementations MUST support size X, SHOULD support size Y, and MAY support larger sizes. Dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Wednesday, November 30, 2005 2:08 PM To: [EMAIL PROTECTED] Subject: [Syslog] #2, max message size - Need to resolve this Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea Please VOTE NOW! Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #5 - character encoding (was: Consensus?)
Hi Sheran, On Tue, 29 Nov 2005, Shyyunn Lin (sheranl) wrote: Chris: I think having SD-ID with [enc=utf-8 lang=English] may be a good approach. If different language use utf-8 encoding, then lang= can distinguish it. We _should_ be using language codes from RFC 3066. That specifies ISO 639 language tags. 639-1 has 2 character codes (en is English) and 639-2 has 3 characters (eng is English). RFC 3066 will likely be replaced by the works of the Language Tag Registry Update (ltru) Working Group. http://www.ietf.org/html.charters/ltru-charter.html They have IDs in the works. Until those become RFCs we should continue to reference RFC 3066. Also want to clarify that you suggest that if the message is in ASCII, it will not required SD-ID, but for all other encodings, SD-ID will be required. Yes - that's my suggestion. Note most other encoding methods already imply the language used, for example, in Chinese, there are several encoding methods, Traditional Chinese used in Taiwan and Hong Kong is Big5, and simplified Chinese used in Mainland China is GBK, so if the message is in traditional Chinese char, it will be shown as [enc=Big5, lang=Traditional Chinese], a little bit redundant. The Big5 also includes all English char so it can be a mix of Chinese and English. Good point. As far as I can tell, Big5 is not recognized by any accredited standards developing organization. It is recognized by the Ideographic Rapporteur Group (IRG) which reports to the Unicode consortium. The recognized way to represent Chinese characters, traditional and simplified, is through ISO 639-2 with the subcodes to indicate traditional and simplified for the zh _language_. The ID on Tags for Identifying Languages http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt identifies simplified Chinese as zh-Hans and traditional Chinese as zh-Hant. Additional subtags could identify a locale such as zh-Hant-TW for Taiwan Chinese in traditional script. This is from the Initial Language Subtag Registry ID. http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-06.txt I think that we should specify encoding and language tags as striaghtforward as possible and let others augment syslog-protocol (in the future) with other encoding mechanisms. We can RECOMMEND that encoding be in UTF-8 and language tags come from RFC 3066. We can allow that other encoding and language identifications are acceptable. In the worst case, a vendor will have the option of [EMAIL PROTECTED]something [EMAIL PROTECTED]piglatin]. Does this work for you? Thanks, Chris Regards, Sheran -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick (clonvick) Sent: Tuesday, November 29, 2005 10:22 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc=utf-8 lang=en] Thoughts? All: Let's discuss this and close this issue. Thanks, Chris On Tue, 29 Nov 2005, Rainer Gerhards wrote: Chris WG, #5 Character encoding in MSG: due to my proof-of-concept implementation, I have raised the (ugly) question if we need to allow encodings other than UTF-8. Please note that this question arises from needs introduced by e.g. POSIX. So we can't easily argue them away by whishful thinking ;) Not even discussed yet. I haven't reviewed that yet. However, I'll note that allowing different encoding can be accomplished in the future as long as we establish a default encoding and a way to identify it in our current work. I have read a little in the mailing archive. Please note that in 2000 it was consensus that the MSG part may contain encodings other then US-ASCII. Follow this threat: http://www.syslog.cc/ietf/autoarc/msg00127.html This discussion lead to RFC 3164 saying other encodings MAY be used. While this was observed behaviour, we need still to be aware that the POSIX (and glibc) API places the restrictions on us that we simply do not know the character encoding used by the application. As such, no *nix syslogd can be programmed to be compliant to syslog-protocol if we demand UTF-8 exclusively. I propose that we RECOMMEND UTF-8 that MUST start with the Unicode Byte Order Mask (BOM) if used. If the MSG part does not start with the BOM, it may be any encoding just as in RFC 3164. I do not see any alternative to this. 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] #5 - character encoding (was: Consensus?)
Hi Rainer, I believe that we are saying the same thing. :) If there is no indicator of encoding or language then a reciever will not know what it is receiving - just like receivers don't know what they are receiving today. They MAY make an assumption that it is something in US-ASCII (but may be disappointed). If there is an indicator of the encoding and language then the receiver will know exactly what it is. Having an indicator should be RECOMMENDED but not REQUIRED for ease of migration. Is that what we're all saying? Thanks, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: Chris, Let's use this email as an example. :) There is no indication that I'm using US-ASCII encoding or that I'm writing in English. I think there actually is. If I am right, the SMTP RFCs require mail text to be US-ASCII. Only via MIME and/or escape characters you can include 8-bit data. For example Müller and Möller might create some problems in some mailers (But I guess my Mail system will encode them with =hexval). Dropping messages with octets 127 in the subject is a common spam protection setting... However, you're able to recieve this and read it. Similarly, you could write an email in German and send it to me. I would still be able to recieve it but I'd have a difficult time parsing the meaning. I'm suggesting that same approach for the transmission of the syslog content. If I really wanted you to know what encoding and language I'm using in an email, I would specify a mime header. syslog senders will continue to pump out whatever encoding and language they've been using and recievers will continue to do their best to parse them. If a vendor wants to get very specific about that, then they will have to use an SD-ID to identify the contents of the message. Here I agree with you. What I was saying is that IF the header says it is US-ASCII, only then we should assume it actually is. If there is no enc SD-ID, then we do not know what it is but can assume ... whatever we assume. Let me phrase it that way: If the message contains [enc=us-ascii lang=en] then the receiver can honestly expect it to be US-ASCII. But if it does not contain any enc the receiver does not know exactly and assume anything it finds useful (may be ASCII, may not). Does this clarify? I somehow have the impression we mean the same thing and I simply do not manage to convey what I intend to ;) Rainer Mit Aufrichtigkeit, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: Andrew, Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc=utf-8 lang=en] I like that idea too. So, if no SD-ID encoding element is specified, then we must assume US-ASCII and deal with it accordingly?? I think not. If it is not present, we known that we do not know it. If it is US-ASCII, I would expect something like [enc=us-ascii lang=en] Of course, we could also say if it is non-present, we can assume US-ASCII. But then we would need to introduce [enc=unknown] for the (common) case where we simply do not know it (again: think POSIX). I find this somehwat confusing. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
Hi, Let's keep in mind that syslog-sign will transport binary signatures. In that, the authors are proposing to use base-64 encoding. I agree with Rainer that we've provided enough means in syslog-protocol so that may be accomplished. As Rainer says, let's focus on getting syslog-protocol finished. :) Thanks, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: Andrew, That sounds good to me at this stage, and it keeps the door open. I would prefer to see all binary data encoded in some safe format like base64. It just makes logging the data to file much easier. For instance, if the binary data contained a LF character, when it was logged to disk, it would end up as two separate messages when opened in notepad etc. While I too prefer a safe format, I would not like to outrule another one. Maybe later... (we *need* to finish this I-D...). How it is handled when writing to disk is beyond IETF. I would escape it then - but that's up to the implementation. Also, if we are to transport syslog over TCP at some stage, we need to keep a delimiter character free from use in the message. Again, a LF would be a good choice for this delimiter. Here, I disagree. I think we can not set aside a character for this. If we go for TCP, let's do octet-couting. Its reliable, efficient and proven. Anyhow, we are not yet doing a TCP mapping, so I suggest we save this discussion until later. Rainer PS: sorry for trying to focus on the immediate needs. But I think we really need to finish something... Cheers Andrew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, 30 November 2005 9:26 p.m. To: [EMAIL PROTECTED] Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting Hi WG, I have received notes via private mail telling me there seem to be some existing (and eventually soon upcoming) valid use cases for binary data in syslog. I think there is no point in arguing whether that's fortunate or not. It simply looks like that's the way it is. I do not like the idea of breaking existing use cases for syslog (because that will only lead to implementors ignoring the spec and the story of syslog inconsistencies continues...). As such, I think we need to provide at least some minimal support for it (aka not outlaw it). At first, this implies that NUL octets may be present in the message. I propose that we write text that discourages the use of NUL, but allows it if needed. That text should also allow, but discourage, a receiver to modify messages containing NUL. With that, we allow the use case, but do not make it a show stopper for implementing compliant software. This would also be pretty much in sync with what we currently find in practice, so it is already expected behaviour. Finally, such text would caution implementors that when NUL octets are present, chancs are high that eventually present digitial signatures will be broken. In my point of view, that's fair and efficient. Chris proposal for #5 (character encoding) also provides an elegant solution for binary data. We can use something like: [enc=binary] or [enc=base-64] I do NOT intend to specify this - I think it should be in the scope of a separate document specifying the use of binary data. Then would also be the right time to discuss all issues that arise out of it. For now, I just would like to keep the door open. Finally, I propose to extend Chris format so that the message size can be conveyed. This has been brought up several times and I think a clean solution is now obvious: [enc=utf-8 lang=en size=MSG-size-in-octets] MSG-size-in-octets would be the size of the MSG part (just that!) in octets. Counting just the MSG part is sufficient, as the rest of the message consists of fields properly delimited. The size is probably most useful for binary data. Please comment. 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
RE: [Syslog] Consensus?
Hi All, I am finding that the people contributing to the mailing list are making progress in defining a useful protocol. I also see that they are discussing implementation details. Both of these tell me that we're on the right track. What we found in Vancouver is that we were on the wrong track. The protocol being discussed was going to break existing receivers and information was going to be dropped on the floor. By keeping PRI, the existing receivers will not drop things on the floor and we can expect a much better acceptance rate from the community. We've seen that RFC 3195 is being implemented. I do not want to de-focus this group by encouraging discussion of that at this time. After we get syslog-protocol and syslog-transport-udp submitted to the IESG, I will ask how we want to proceed with a revision of that Proposed Standard. One person has suggested to me that it can be revised through an individual submissionn. Rainer's list (below) will serve as our list of issues. I'd like for these to be closed out within 2 weeks. I'm going to look for rough consensus on these issues and I will greatly appreciate everyone accepting the decisions we make at the end of that time. After that, I'll ask for Rainer to submit a new ID. If needed, I'll also ask for Anton to submit a new ID. I'll allow a week of review on those. If we still see implementors willing to implement this then we will progress these to the IESG. Addtional comments below. On Fri, 25 Nov 2005, Rainer Gerhards wrote: Tom, WG: Comments inline... Rainer [tp] Strange, I was thiinking quite the opposite, that we had a fragile consensus which disappeared in Vancouver and has not been refound. Looking back at the messages posted in the past few days, about what should be in the header in what order, I was thinking, what now? because I see no consensus, rather the re-emergence of many different points of view. So while the proposed charter looks ok, because it does not go into that detail, I do not see how we progress any further, into the next level of technical detail, of what and how should be in the header. I agree that we have not found consensus again. However, I think we are in a better shape on the details than it it might look. My personal view is that many items are shortly before reaching actual consensus. Let me sum up the items I see. We might use that as a potential basis for reaching consensus. #1 testing and code review has shown that there is no point in trying to preserve more than PRI; RFC 3164 provides a false impression of common behaviour. This is controversal, but the facts are suggesting this is the way it is. We should try to reach consensus on this. 3164 was written based upon what Eric told me of how things originally worked. Obviously not much has stayed that way since. We can accept that things are received and placed in the right bins if a message has PRI. I'm OK with keeping that and defining the rest of the message as long as we keep the free-form text which has been the basis of syslog for all of these years. #2 The max message length issue resurfaces. There seems to be a fragile consensus that we can life with the compromise in syslog-protocol and eventualy open a debate if we (ever) go to a TCP transport. Again, controversal, too. #3 There is a question if NUL octets are to be supported in the MSG content. No consensus yet. #4 There seems to be a fragile consensus that MSG should primarily contain textual data, including XMLified content. On the contrary, pure binary data should not be used. This is somewhat controversal. If we can agree that a natural language indicator (likely an SD-ID element) can be defined, then I believe that we are setting the stage so that future definitions may be made to allow for XML, binary, and perhaps even Martian. Those are outside of the current scope of the WG. Let's concentrate on transferring the textual information. #5 Character encoding in MSG: due to my proof-of-concept implementation, I have raised the (ugly) question if we need to allow encodings other than UTF-8. Please note that this question arises from needs introduced by e.g. POSIX. So we can't easily argue them away by whishful thinking ;) Not even discussed yet. I haven't reviewed that yet. However, I'll note that allowing different encoding can be accomplished in the future as long as we establish a default encoding and a way to identify it in our current work. #6 field order This is related to #1 and can, I think, quickly be fixed once #1 is settled. Agreed. #7 Header fields: there seems to be a fragile consensus that MSGID, PROCID, APP-NAME, and VERSION should be in the header and TRUNCATE should not be in it. This needs to be finalized, but I think we are very close. Agreed. #8 MSG-octet counting and/or trailer is resurfacing. I think this item is not well understood and well
[Syslog] Secure substrate - need your input
Hi Folks, I'll be asking this in Vancouver but would like to get some input from the mailing list. Our charter says that we will develop a secure method to transport syslog messages. We have BEEP (RFC 3195) but it has a low implementation record. Other groups have specified BEEP as well but are also moving along towards using SSH or SSL. 1) What secure substrate should the WG look towards: __ ssl __ ssh __ dtls http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt __ other 2) Why? Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] TCP and SSH Discussion
Hi Darren, On Sat, 22 Oct 2005, Darren Reed wrote: Hi Darren, It's not syslog/udp/ssh nor syslog/tcp/ssh, it's going to be syslog/ssh/tcp/ip. syslog will be a defined subsystem for SSH much like sftp and netconf. Oh! Hmmm. Do you have any links to critiques about sftp ? The secsh wg mailing list. ;) ftp://ftp.ietf.org/ietf-mail-archive/secsh/ I've spoken to at least one person recently (but I can't recall *who*) that wasn't too impressed with sftp, so I'm curious if there is anything substantial that discusses its drawbacks and what lessons (if any) need to be learnt from it. Joseph Galbriath has offered to have a bar-bof to discuss sftp. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] TCP and SSH Discussion - where are we heading to?
Hi Rainer, On Fri, 21 Oct 2005, Rainer Gerhards wrote: Chris, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Are you volunteering to write? :) I think we are not yet in a position we have something to write. I know that you probably did not mean to start anything right now, but let me use this message as a tool to voice my concerns. Over the past months (years), we've done some good work in evolving syslog. However, RFC 3195 is having a very hard time among implementors and our last efforts on protocol have received very limited feedback from the operator/end user camp. On the other hand, I know that there *is* vital interest in syslog. It's easy to judge this by the interest new implementations receive from the user base and also by the number of deployments of syslog tools. Obviously, end-users tend to be interested more in the actual software tools than in protocols. But the low implementor participation and end-user adoption rate is raising a very important question to me: are we still heading into the right direction? What does it help if we create better and better standards (assumed they are, which is obviously arguable) but nobody cares? In practice, mostly non-official-standard solutions are being asked form, developed and deployed. For example, I will begin to implement plain tcp syslog with ssl encryption shortly. Not because it is so secure or reliable - simply because there is so much demand for it. Current approaches typically use plain tcp syslog together with stunnel (which, by the way, is valid solution for many needs). May be it is just me feeling some asynchronicity between what the field is asking for and what we are doing. If so, I would suggest that we try to obtain some broader feedback from operators and implementors before going any further with new standards. If there is a sufficiently large group of operators (maybe just in terms of purchasing power) asking for some new protocol (or protocol versions), we can probably make the implementors implement them. Currently, I honestly feel it very hard to provide business reasoning for creating something new... Very good points. I've gotten a few separate emails asking if this is the right direction. I'll raise this discussion in a new thread on the mailing list. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
