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

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 24 Jan 2005 16:29:23 -0500

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.

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.

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

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

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)

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.

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?

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.

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  "< .. >"

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. 

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.

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

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?

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?

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

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.

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.

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?

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.

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.

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.

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?

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.

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.

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.  

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?

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. 
S24.2 The third paragraph in section 8.2 defines requirements. 
S24.3 Last paragraph in 8.2 defines requirements and not the same as defined
in 6.3 
S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security
considerations. 
S24.5 Also the last sentence in the first paragraph of 8.4 seems completely
off topic.

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?

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.

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)

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?

Wordsmithing
------------

W1. Section 6.2.4.1 second paragraph needs wordsmithing.

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

W3 In section 8.4, second & third paragraphs need wordsmithing

W4 In section 8.8, the last sentence, this should say it is a "replay"
attack and not a "reply" attack. 

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

W6. In section A.3, second paragraph, also include the textual description
that pertains to this severity number. 

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