Hi Chris & all, thanks for the comments. I have integrated them. While doing so, some points were raised. I would appreciate if you could go through my reply below. There are some question in it. I have also added comments related to Didier's posting on message truncation. They are at the end of this posting.
I will hold the protocol-14 update to see if I receive some replies to this posting. If I hear nothing, I will post on monday. Sorry this has become a large posting, but I would prefer to get some feedback before I post the next release (given the fact we are close to final call). Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Chris Lonvick > Sent: Tuesday, July 05, 2005 4:01 PM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Chair Review Comments of > draft-ietf-syslog-protocol-13 > > Hi Folks, > > I've done a review of draft-ietf-syslog-protocol-13 and have > the following > comments. I'd like to ask Rainer to incorporate them along > with any other > final comments and publish a new version. Once this is in the ID > repository I will call for WG Last Call for two weeks. If we > don't get > any major issues from that then I'll submit it to the IESG with the > recommendation that it be considered for publication. I'll be doing a > review of syslog-transport-udp as well. > > > > References are not allowed in the Abstract. Suggest change: > This document has been written with the spirit of RFC 3164 [14] in > to: > This document has been written with the spirit of > tradition syslog in > Keeping the reference in the Introduction is OK. done > > > "Conventions Used in This Document" should be: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as > described in > RFC 2119. > (That's how it's written in RFC 2119.) In some cases the keyword > "optional" should be in uppercase in the document - like in > several places > in Section 7. > done (including section 7) > > Double dashes in Basic Pricipals are not to be used. Suggest change > o Relays may send all or some of the messages that they > receive to a > subsequent relay or collector. They may also store -- or > otherwise locally process -- some or all messages without > forwarding. In those cases, they are acting as both a collector > and a relay. > to: > o Relays may send all or some of the messages that they > receive to a > subsequent relay or collector. They may also store or otherwise > locally process some or all messages without > forwarding. In those > cases, they are acting as both a collector and a relay. > Also, this is not entirely clear. Perhaps it should be changed to: > o Relays may send all or some of the messages that they > receive to a > subsequent relay or collector. They may also store or otherwise > locally process some or all messages without forwarding. In the > case where a receiver stores some messages and relays some > messages, it is acting as both a collector and a relay. > changed to the text you suggested (directly above this sentence) > > Watch the contignuity of the diagram 1 and its title. Make sure that > they are not separated by a page break. The RFC editor will also > watch this. I needed to squeze it a little, but I think it is still readable well enough. Don't like the idea to drop one of the scenarios... > > > In Section 6.1 "Message Length", the following paragraphs may > be clearer > if they are reversed: > If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA > field MUST be changed to "-" to indicate empty STRUCTURED-DATA. > > When a receiver or initial sender truncates a message, the TRUNCATE > (Section 6.2.4) field MUST be updated. In the case of a receiver, > please note that this will break eventually existing digital > signatures. This is irrelevant, as the truncation itself > breaks the > signature. So no extra harm is done by updating the > TRUNCATE field. > Also, the clause > please note that this will break eventually existing digital > signatures. > should be changed to: > please note that this will break message integrity checking > mechanisms such as digital signatures. > done > > Would it be appropriate in Section 6.2.1 "VERSION" to describe that > the VERSION field can only be changed by STANDARDS ACTIONS as defined > in RFC 2434? Also, the VERSION needs to be registered with > IANA and needs > to be stated in the instructions to the IANA. I've changed it to "Standards Action" in 9.1. Do you think I actually need to repeat this in 6.2.1? Does 9.2 also require "Standards Action" or is "Specification Required" (as it is currently) sufficient? I am a bit in doubt, maybe it's better to keep this consistent. > > > In Section 6.2.2 "FACILITY", the value of the facility should not > have commas. > FACILITY is an integer in the range from 0 to > 2,147,483,647. It can > change to: > FACILITY is an integer in the range from 0 to 2147483647. It can done > > > If diagram 1 has a title, then so should the diagram (or > table) in Section > 6.2.3 "SEVERITY". > done > > The list in Section 6.2.3.1 "Relation to Alarm MIB" may be better > represented in a table. I have changed the layout and included Sharon's latest comment on the mappings. I hope the mapping is now acceptable to all. The new text is as follows: ### 6.2.3.1 Relation to Alarm MIB The Alarm MIB RFC3877 [11] defines ITU perceived severities which are useful to be able to relate to the syslog severities, particularly in the case where alarms are being logged. The ITUPerceivedSeverity corresponds to a syslog SEVERITY as shown in table 2 below. ITU Perceivedi Severity syslog SEVERITY Critical Alert Major Critical Minor Error Warning Warning Indeterminate Notice Cleared Notice Table 2. ITUPerceivedSeverity to syslog SEVERITY mapping. ### > > > The table in Section 6.2.4 "TRUNCATE" should have a title. done > > > Grammar in Section 6.3.3 "SD-PARAM": > MAY drop the message. It is RECOMMENDED that the receiver logs a > diagnostic on reception of invalid escape sequences. > should be changed to: > MAY drop the message. It is RECOMMENDED that the receiver log a > diagnostic message on receipt of a message with an invalid escape > sequence. done > > > Section 6.3.4 "Change Control" should either be move to the IANA > Considerations or be duplicated there. > Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of > these objects MUST NOT be altered. Should a change to an existing > object be desired, a new one MUST be created and the old one remain > unchanged. > A slight change may make it more readable: > Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of > these objects MUST NOT be altered. Should a change to an existing > object be desired, a new SD-ID MUST be created and the old > one remain > unchanged. > done with a slight change: ### a new SD-ID or PARAM-NAME MUST be created and the old one remain unchanged. ### duplicated to IANA considerations, but mentioning only SD-IDs there. Which brings up the question: must we put PARAM-Names under IANA-Control, too? It kind of looks so... > > In Section 7.3.1 "sequenceId", commas should be removed from > the number. > message up to a maximum value of 2,147,483,647. If that value is > should be changed to: > message up to a maximum value of 2147483647. If that value is done > > > Grammar in Section 8.4 > In case a sender includes user-supplied data within a > syslog message, > it should limit the size of that data. Otherwise, an attacker may > provide large data in the hope to exploit this potential weakness. > should be changed to: > A sender should limit the size of any user-supplied data within a > syslog message. If it does not, an attacker may provide > large data in > hopes of exploiting a potential weakness. done > (Rainer may consider adding something about rate limiting > here as well.) I have included some information on rate limiting a bit later, in 8.6. The suggested text is: ### 8.6 Reliable Delivery Because there is no mechanism described within this document to ensure delivery, and the underlying transport may be unreliable (e.g., UDP), some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of dropping one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may either not be noticed, or it may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities. It may be desirable to use a transport with guaranteed delivery, to mitigate congestion. It may also be desirable to include rate-limiting features in syslog senders. This can reduce potential congestion problems when message bursts happen. ### I think talking about rate-limiting on the receiver's side does not make so much sense, as it will result in message loss in any case (at least with UDP transport). Do you think the proposed text is OK? > > > In the Instructions to IANA, it should be noted how additional > SD-PARAM names are added. For example, how would one go about adding > a new SD-PARAM to describe the timezone on Mars to the timeQuality > SD-ID? In that case, the SD-ID is not being changed, only a > new SD-PARAM > is being added. I have changed the text to cover this: ### 9.2 SD-IDs IANA must maintain a registry of Structured Data ID (SD-ID) values together with their associated PARAM-NAME values as described in Section 7. New SD-ID and new PARAM-NAME values may be registered through the Specification Required method as described in RFC 2434 [9]. Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or SD-PARAM MUST be created and the old one remain unchanged. IANA must register the SD-IDs and PARAM-NAMEs shown in table 4 below. ### I have also changed the SD-PARAM description: ### 6.3.3 SD-PARAM Each SD-PARAM consist of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE. PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, with the exception of those in experimental SD-IDs. The PARAM-NAME scope is within a specific SD-ID. Thus, an equally-named PARAM-NAME contained in two different SD-IDs is not the same. ### However, this raises a question: should we allow experimental SD-PARAMs in standardized SD-IDs? Or should these only be allowed in experimental SD-IDs (x-)? > > > The instructions to the IANA should give a table of SD-IDs and their > known SD-PARAMS. > SD-ID SD-PARAM > > timeQuality OPTIONAL > tzKnown OPTIONAL > isSynced OPTIONAL > syncAccuracy OPTIONAL > > origin OPTIONAL > ip OPTIONAL > enterpriseId OPTIONAL > software OPTIONAL > swVersion OPTIONAL > > meta OPTIONAL > sequenceId OPTIONAL > sysUpTime OPTIONAL > > The IANA seems to like maintaining tables better than just textual > registries. > Chris, I am not sure if the "must" below must be in upper case (as it is no protocol related thing). I'd appreciate your advise: ### IANA must register the SD-IDs shown in table 4 below. ### ^^^^ Regarding Didier's comments on the truncation process, I have added the following section: ### A.3 Message Truncation As outlined in Section 6.1, messages may be subject to truncation. In this case, the TRUNCATE field must be updated as specified in Section 6.2.4. Implementors must keep in mind that the TRUNCATE field is a variable-sized entity. Thus, its size requirement (in octets) may grow during truncation. For example, if a relay truncates the MSG part of a message previously not truncated, the TRUNCATE field value changes from 0 to 10, taking up one additional octet of space. As such, it is necessary to truncate one additional octet from the MSG to make room for the now-expanded HEADER. Similar reformatting may be necessary if a relay is operator- instructed to perform header modifications, e.g. to change the FACILITY or SEVERITY of a message before forwarding it. ### I have also changed the values of the TRUNCATE bits to something that I think making it less likely to grow: ### 6.2.4 TRUNCATE The TRUNCATE field is used to indicate if the message has been truncated since it was sent or generated by an application. Such a truncation might happen on the initial sender and any receiver, including receivers on interim systems (relays). Values in the TRUNCATE field are made up of bits. Each of this bits has been assigned a specific value so that there is no doubt about bit ordering. The values described in table 3 below MUST be used. VALUE Meaning 1 all or some SD-ELEMENTs were truncated 2 all or part of MSG was truncated 4 truncation occurred at the receiver 8 truncation occurred at an interim system 16 truncation occurred at the initial sender Table 3. TRUNCATE values. ### _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
