RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Hi WG,

the message below was accidently sent only to Sharon. I am now resending
to the mailing list.

Rainer

----------------
Hi Sharon,

it took some time to compile all my responses. In the mean time, I've
done many edits to syslog-protocol. I've already brought up some of the
issues on list. With this mail, I

- tell what I have changed
- provide reasoning of what I have not changed 
- ask some new questions

I have a considerably changed ID over here. I will wait for some
responses, but I am not sure if I can manage to integrate them into the
draft tomorow. In any case, I will post a new draft to the draft editor
tomorrow evening, so that the most current version is in the
ID-repository.

I would once again like to thank you for your good feedback and the
excellent form  in which you provided it. That really eased my job of
tweaking the draft.

Rainer

> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org 
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of 
> Sharon Chisholm
> Sent: Monday, January 24, 2005 10:29 PM
> To: syslog-sec@employees.org
> Subject: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09
> 
> hi
> 
> Here are some rather detailed review comments on the Syslog Protocol
> Document. I figured it would be better to raise them now 
> rather then wait
> for working group last call. It looks like a lot, but I think 
> that is due,
> in part, to how I broke things up into smaller specific 
> comments which I
> hope makes them easier to address.
> 
> I have divided the comments into general, substantive and 
> wordsmithing.
> 
> General Comments
> ----------------
> 
> G1 - Syslog is stored on disk, but there is no discussion on 
> inter-record
> separator on disk. Carriage return would be a good choice, but has
> implications on message content unless it is escaped.

Added exclusion of storage format to intro (see previous on-list
discussion).

> 
> G2 - Not much is said about change control and backwards 
> compatibility other
> than the discussion buried in  A.2 which seems to imply there 
> isn't any. I
> propose the following:
> 
> G.2.1. Make a statement to set expectations about change 
> control within the
> body of the document.
> 
> G.2.2. Suggest two levels of expectations - one for the 
> header, which is
> governed by the version number and one for the SD-PARAMs 
> which should be
> somewhat independent of it. I recommend that people try not 
> to break things
> in the SD area within a version and between versions. Same 
> name has same
> general semantics. If not a MUST, this needs to be a SHOULD. 
> I vote for
> MUST.

I added some descriptive text to 6.2.1 (VERSION). But I think it already
covered that no header modifications are allowed. So some folks on this
list might reject this as a duplicate.

For STRUCTURED-DATA, I have added the following new section:

###
6.3.4  Change Control

   Once SD-IDs and PARAM-NAMEs are defined in a specification and their
   IANA assignment has been done, syntax and semantics of these objects
   MUST NOT be altered.  So they begin to exist with their initial
   definition and are never allowed to change.  Should a change to an
   existing object be needed, a new one MUST be created.  It is advised
   to use a name the reflects the close relationship between the two
objects.
   For example, if the semantics of the "tzKnown" PARAM-NAME were to be
   changed, a good name for the new element would be "tzKnown2".
###

> 
> G.3 Suggest adding a 'Relationship with BSD Syslog' section to answer
> comment questions. Some text already in A7.
> 

added - separate discussion; seems to be accepted by WG (lack of further
response)

> G4. The non-normative appendix uses requirements-like language - MUST,
> SHOULD, etc. What does that mean?

removed that, changed to lower case

> 
> Substantive Comments
> --------------------
> 
> S1. In section 6, what is the relationship between Facility 
> and MSG-ID? They
> seem to serve the same purpose. Is Facility just historical? 
> Is MSG-ID what
> we need to use moving forward? (see G3)

I added this text to the description of FACILITY:

####
It is RECOMMENDED that the facility
reflects a type of subsystem, something that a number of different
messages
might be issued from. So it is a kind of corase group.
####

Does this clarify? Do we need to add similar text to MSGID (in that it
identifies a specific message)? To keep it short, I've not done this
yet.

> 
> S2. Is the length of SENDER-NAME and SENDER-INST sensible? 
> SENDER-INST seems
> way too short. Consider needing to name something which is 
> the concatenation
> of two IP addresses. It does not fit. Remember this is the 
> encoding the
> string, not the integer. We will end up forcing people to 
> make up something
> which does fit instead of using something existing.

Actually, SENDER-NAME and -INST are not meant to be IP addresses. We
have HOSTNAME and ORIGIN for that. SENDER-NAME and -INST should identify
the type of sender, most probably a process name or something similar
(like "postfix", "su" in current messages in TAG). I think the size is
sufficient for this purpose. Given the size limitation we have in UDP
based syslog, I would like to keep the HEADER size as small as possible.
Obviously, we should not sacrifice things for a short size, but I think
we do not need the longer sizes here.

> 
> S3. In section 6.1, we need some guidelines on how to truncate
> SD-BOUNDARIES. 
> Can the structured data become non-compliant or must it still 
> be valid? If
> within the message part, is it just arbitrary?  Should we indicate
> truncation has occurred in the header or at the very end of 
> the message? Do
> we need to leave room for some extra characters at the end to 
> signify the
> message has been truncated?

This is being discussed in a separate thread.

> 
> S4. In section 6.1, this should really only recommend 
> truncation. Delete the
> bit about dropping the message or indicate that it is only 
> dropped when
> truncation cannot result in a valid message. That assumes we 
> think that is a
> possibility, if not, lose the bit about dropping all together.

I am not fully with you here. The "drop it" rule was added for receivers
in embedded devices. Among others, it was argued that it might not be
possible to receive the full message. Though we currently do not have a
trailer, it can be argued that in this case the trailer could not be
received and thus not only the payload, but the message itself would be
truncated. It was assumed that embedded devices might prefer to drop the
message instead of truncating it.

Also, with the UDP transport, it is sheer reality that messages can be
dropped on the network, especially if the network itself is experiencing
troubles. So allowing a device to drop a message larger than 480 bytes
could/should encourage implementors to keep them shorter than that.

Of course, it can be argued that this is something that should be moved
to security considerations or implementors notes - where it also is
present. The two arguments together, however, seem to justify the "drop
rule". I have to admit, though, that I am not very strong with this
argument. If you feel this is really bad, please press again for change,
I think a good argument can break my current one.

> 
> S5. In section 6.2.1, discussion about how to tell the 
> difference between
> these versions and BSD versions should also be included 
> unless it is covered
> in G3. I believe the BSD stuff is all about  "< .. >"

Will go into a separate appendix section. Already discussed on-list.

> 
> S6. In section 6.2.1, this section should really include a 
> pointer to the
> IANA Considerations section so people don't get the idea that 
> they can just
> create new versions of syslog themselves. 

added

> 
> S7. In relation to section 6.2.3, do we want to add a section called
> 'Relationship to the Alarm MIB' so we can discuss the mapping 
> of severities?
> This is something that has come up in private discussions 
> since these do
> differ somewhat from ever popular OSI severities. I could 
> write this section
> up if there is interest. Terribly useful in the case of 
> someone logging
> alarms.
> 

This has been added - text proposed to WG, some feedback received but
should be further reviewed

> S8. In section 6.2.5, do we really want to call this 
> hostname? Would sysName
> not be better?

I think we should stick with HOSTNAME, because this is the traditional
syslog term for it. It might be easier for other folks to deal with
"sysName", but I think - to gain acceptance - syslog-protocol should use
as many syslog terms as fit in the new context.

> 
> S9  In section 6.2.6, have we not already identified the device via
> hostname? Should this not just be application? Should we rename it to
> reflect this?

This is very similar to a comment Anton Okmianski made. He suggested
that SENDER-NAME and SENDER-INST be renamed to APP-NAME and PROCESS.
Please see my arguments at

http://www.employees.org/pipermail/syslog-sec/2005-January/000092.html

After reading your post, I begin to think that Anton was right and we
should rename this. What do you think?
 
> S10. In section 6.2.7, it includes the operating system 
> process ID? Does
> this make sense in the typical IETF problem space? What about 
> multi-computer
> network element? Can we just delete this part of the description?

The idea in recommending a process id is that we need some relative
uniqueness to detect restarts of the syslog daemon. So we do not
necessarily need the process ID, we need something that changes when the
instance of the sender changes. Of course, this is not absolutely vital
(just helpful), this is why we allow the "-" nil value.

> 
> S11. In section 6.2.7, in the discussion about "-", does this 
> just mean that
> a single value that is "-" is not allowed or that any use of the "-"
> character. For example, would "1-1-1-1-1" be considered 
> valid? Note this is
> a real-world value that someone would want to subscribe and not just a
> theoretical corner case. Same comment for 6.2.8

ahhh... yes! OK, it is not actually the character but the field value.
will change...

> 
> S12. In section 6.2.8, MSGID seems like a bad name.  ID implies
> per-instance. Or is this not what you meant? MSGTYPE would be better
> otherwise. The definition and subsequent examples make it 
> difficult to tell
> how this field is intended to be used.

I see what you mean. I've changed the text as follows:

####
The MSGID SHOULD identify the type of message. For example, a
Firewall might use the MSGID "TCPIN" for incoming TCP traffic
and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with
the same MSGID should reflect events of the same semantics.
The MSGID itself is a string without further
semantics. It is intended for filtering messages
on the receiver.
###

I guess a have some language issue here, the text doesn't sound as clear
to me as I intend it to be. Any help in getting it straight would be
appreciated.

> 
> S13. In section 6.3, should the relay really muck about in 
> the content? They
> should pass it along shouldn't they? I recommend deleting the 
> option to
> discard in this section.

I see the reasoning and have removed the discard option.

> 
> S14. In section 6.3.1, Should this case sensitive discussion 
> not be moved
> down to the specific section for SD-ID and SD-PARAM or did I 
> misunderstand
> the meaning?

you are right, moved down

> 
> S15. In section 6.3.2, can the same SD-ID exist multiple 
> times in the same
> message. Hopefully the answer is no. This should be stated.

right: no. Added that.

> 
> S16. In section 6.3.2, the requirement is ambiguous. It 
> should be rephrased
> as 'Experimental or vendor-specific SD-ID MUST start with 
> "x-".  Anything
> that doesn't is managed by IANA.

much better text. replaced my text with your suggestion.

> 
> S17. In section 6.3.3, a note should be added saying that 
> SD-PARAM can be
> repeated multiple times like in the IP example. This is 
> generally useful.

added

> 
> S18. In section 6.5, the example, the 2 space thing is 
> inconsistent with
> previous use of "-" character to indicate no value. Is there 
> a reason for
> this and why is this buried in an example?

This is a result of the ABNF. So far, we have not defined that the
non-existance of any STRUCTURED-DATA must be denoted by anything. As
such, it is SP <empty STRUCUTRED-DATA> SP, ultimately leading to two SP
after each other.

If you feel we should explicitely denote missing STRUCTURED-DATA (and
nobody objects), I can add this. "-" would be appropriate in this case,
because it is used everywhere else in the draft for this purpose.

> 
> S19. In section 7, suggest new optional SD-PARAM called 
> sequence ID, whose
> scope is a sub-domain of a network element. Reset on reboot. 
> Also, perhaps
> one for sysUptime.

I like this idea, but ask for some clarification.

For "sequenceID", I assume it should be incremented for each message
sent? Is that right? If so, I'd suggest an unsigned 32 bit integer with
automatic rollover/reset to 0 after the maximum value is reached.

As far as sysUptime is concerned, I think we should stick with the SNMP
definition of the number of milliseconds since boot, with a max value of
4294967295 and automatic reset to zero thereafter. Is this understanding
correct?

For both, I think it would not be appropriate to add them to the
"origin" SD-ID. Maybe it would make sense to add a "meta" SD-ID which
can hold information somewhat describing the message.

Any comments would be appreciated, including SD-ID name suggestions.

> 
> S20. In section 7.1, time really need to be renamed to be 
> something that
> won't get confused with a  timestamp. I've previously been 
> confused by this.
> Recommend calling it timeQuality.

You are right. I've renamed it to timeQuality.

> 
> S21. As a general comment to the 7.1.* sections, it would 
> seem that the
> optionality of the parameter has been confused with the 
> optionality of its
> behaviour. If the SD-PARAM is present, the behaviour MUST be 
> as described.  

Acutally, I thought this was in the question. Maybe this is a language
issue. Could you point me to what exactly makes the behaviour optional
(it was not intended to be).

> 
> S22. In section 7.2.2, is this really identifying the 
> enterprise and not the
> actual device type like something like sysObjectId would? 
> Actual device type
> would be more useful.
> 
> S23. In section 7.2.3, how does software differ from 
> sender-name where they
> talk about an application?

S22 and S23 deserve a single answer. Yes, it is an enterprise, but the
idea is that we have the enterprise, the name of the software as well as
its version. That should uniquely identfy who is talking and in what
(freeform MSG) format.

> 
> S24. In section 8, a general note on the security 
> considerations section is
> that a lot of the content is not. The non-security 
> considerations content
> should be moved elsewhere or reworked to be an actual security
> consideration. Also, there appears to be requirements buried 
> in here, which
> also does not seem appropriate.
> 
> S24.1 The last paragraph in section 8.1 is not a security 
> consideration. 

I think it is, but I may be wrong: my intention was to warn against too
verbose logging, because it is very often seen that logging is turned
off if it is too verbose. Does this really not fit in here?

> S24.2 The third paragraph in section 8.2 defines requirements. 

I think I can simply change the "SHOULD NOT" to lower case - storage is
beyond the scope of this document. Or should I actually drop it - but it
*is* a very important security issue...

> S24.3 Last paragraph in 8.2 defines requirements and not the 
> same as defined
> in 6.3 

overlooked leftover - deleted

> S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security
> considerations. 

Why is 8.4 not a security consideration? [honest question, not
suggestively meant ;)]

8.5 to 7.7 are carried over from RFC 3164. They are security
considerations there, too. Why shouldn't they apply here?


> S24.5 Also the last sentence in the first paragraph of 8.4 
> seems completely
> off topic.

syslog is simplex delivery. nobody will notice if the message is lost.
This is telling the fact and informing the implementor that the protocol
might not be suitable for a specific application. Should I still drop
it?

> 
> S25. In section 8.12, the last sentence, what is it saying? 
> What does a
> reliable transport mapping mechanism have to do with operator 
> error? This
> claims that 'Using a reliable transport mapping can guard 
> against these
> problems' How?

A reliable transport mechanism with notifications (e.g. RFC 3195/COOKED)
can detect such loops. Thus it can guard against them.

> 
> S26. In section 8.16, where is our definition of a channel 
> coming from? What
> about the other terms discussed here? They don't seem to have been
> introduced.

I now think this section can be removed at all without any loss. I'll do
that if nobody objects.
> 
> S27. In section 10, the IANA Considerations section should 
> really have a
> section that states "The following is the initial set of 
> SD-PARAMS ... this
> is how we manage the IETF portion of this name space"
> 
> S28. In section A.1, first paragraph, talks about truncation, but the
> requirement in the main body of the draft allows dropping as currently
> written. (See other recommendation to delete the drop option)

I agree on the inconsistence, but would like to finish the discussion on
the drop option first. Once this is done, I will fix the text down here.

> 
> S29. In section A.2, what does the last sentence in the second last
> paragraph mean? "It would be considered good form if the 
> receiver were to
> attempt to ensure that no application reliability issues 
> occur." Don't write
> bad code?

yes ;) - removed

> 
> 
> Wordsmithing
> ------------
> 
> W1. Section 6.2.4.1 second paragraph needs wordsmithing.

hopefully resolved

> 
> W2. In section 8.1, first sentence needs to be wordsmithed. Recommend
> removing phrase 'in multiple sections'

removed as suggested

> 
> W3 In section 8.4, second & third paragraphs need wordsmithing

changed, hopefully more clear now
> 
> W4 In section 8.8, the last sentence, this should say it is a "replay"
> attack and not a "reply" attack. 

fixed

> 
> W5. Second paragraph in Section A1, needs to be wordsmithed. 
> "Restriction
> deliberately to deliberately avoid", Troubleshoot -> 
> troubleshooted?, "Some
> UPD implementation generally do"

fixed

> 
> 
> Sharon Chisholm
> Nortel Networks
> Ottawa, Ontario
> Canada
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec