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
RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, Ahh.. I see your point now. (Sorry - being a little slow this week.) All: I'm tending to agree with Rainer's point that no value should be specified for APP-NAME. Does anyone think that the document should suggest something for fixed-function devices such as printers which might not have a syslogd? Currently syslog-protocol allows a NILVALUE if nothing better can be used. I think they should use whatever the use with other messages. For example, they might use router. Sure, this is not intelligent. But my point is that this should not be of concern for syslog-sign. Similarly, PROCID may be NIVALUE in syslog-protocol if the device cannot produce it. I'm OK with that for syslog-sign as well. Finally, I'd still like to keep sig for the MSGID. This should allow for parsers (automated and manual searches) to find syslog-sign messages quickly. I do not object it, as long as we caution implementors that a MSGID of sig does not necessarily indicate this is a syslog-sign message. We can not guarantee that, because we did not reserve any message ids at all. So it may be a clue, but it is nothing to rely on. Which brings me to the point: what is the advantage of an unreliable indicator? This won't be the only mechanism to identify a syslog-sign message. I believe that a syslog-sign message would have to: - be sent to PRI = 110 - have MSGID = sig - contain an SD-ID with the SD-PARAM of ssign or ssign-cert I don't think that we need a registry of MSGIDs for this. For me, the SD-ID is the only valid indicator that this is a syslog-sign message. We can not rely on PRI as operators like to reconfigure PRI. Even if we mandate a fixed PRI in the specification, real-world implementations will ignore that requirement and still allow the operator to override it (and this for a good reason). On the other hand, SD-IDs *are* under IANA control and the absolutely positively identify the element that they are contained in. This is what we designed them for. So why not use them for their design purpose? With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer If anyone has issues with any of this, please speak up now. I'd like to get this settled so we can update and send this to the IESG when the WGLC ends. Thanks, Chis On Tue, 19 Dec 2006, Rainer Gerhards wrote: Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 10:18 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, On Mon, 18 Dec 2006, Rainer Gerhards wrote: Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so
RE: [Syslog] 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
RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 10:18 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Hi Rainer, On Mon, 18 Dec 2006, Rainer Gerhards wrote: Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. We're going to have ssign and ssign-cert as the SD-IDs used for syslog-sign. I don't think that there are any dependencies on APP-NAME, PROCID and MSGID for the proper working of syslog-sign; From the quoted text above: value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double If APP-NAME and MSG-ID *MUST* contain something specific, I think there is a strong dependency. they're just there to make sure that these messages are placed consistently into the right bins. The ssign and ssign-cert SD-IDs will be reserved for this. I do not see how this addresses the concerns I mentioned above. I can not implement it without interfering with my application design in a way that I do not find justified. How does mandating a specific APP-NAME and MSG-ID make sure that they are put into the right bins? Many stock syslogds can not even filter on these fields... Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[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] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
Hi, So far, I have not been able to do a full review. But this triggers my attention immediately... Perhaps restructure that as: A Signature Block message that is compliant with RFC [14] MUST contain valid APP-NAME, PROCID, and MSGID fields. Specifically, the value for APP-NAME MUST be syslog (without the double quotes). The value for MSG-ID MUST be sig (without the double quotes). The value for the PRI field MSUT be 110, corresponding to facility 13 and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. Similar in Section 5.3.1. Syslog-protocol does not reserve any specific values for APP-NAME, PROCID and MSGID. So (at least theoretically), another implementor migth use the suggested values for any other case. As an implementor, I would probably like to consistenly use the same APP-NAME. For example, all messages in rsyslog will be logged as rsyslogd. I have just quickly read the IANA section (9.1): there is no such registry like APP-NAME. It might eventually be a good idea to create one, but I am not sure if it is worth the trouble. In any case, I think that must be spelled out in -protocol (else I can implement somthing compliant to -protocol but not -sign). Same goes for MSGID. My recommendation (without a full read of the document...) is to remove any dependencies on APP-NAME, PROCID and MSGID and use structured data fields for them. Otherwise, I foresee that I need a lot of hardcoded exception inside a syslog implementation to mangle this fields so that the happen to be right for -sign while they are invalid from the overall application point of view. -- Version field: I recommend renaming it to something like Sig-Version to avoid mistaking -protocol VERSION and -sign Version. -- I hope I will be able to do a full review by the end of the week. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
