[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III
hi
Part III of my response. This is the last of the series, but I owe one more
on the truncation thread.
<Rainer>
>
> 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-existence 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 explicitly 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.
</Rainer>
No, the structured data should just not be there if it is optional and not
supported. What I was referring to was text like the following in 6.2.7:
"The dash ("-") is a reserved SENDER-INST field value that MUST only be used
to indicate an unidentified instance." and in section 6.5 "Note the two SP
characters following MSGID. The second SP character is the STRUCTURED-DATA
delimiter. It tells that no STRUCTURED-DATA is present in this message."
What I was trying to do was 1) Get us to realize the syntax between the two
was different and ensure we had a good reason for that 2) Get the
description of this interpretation of the two SP character moved up into a
more appropriate part of the document
<Rainer>
>
> 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.
</Rainer>
Yes, you are correct - in addition to being reset on reboot, the sequence ID
needs to define its roll-over behaviour.
I agree they don't belong in origin, but I'm not sure 'meta' is the correct
SD-ID. I can't think of anything better at the moment though. Go with that
until someone else can think of something more clever.
<Rainer>
> 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.
Actually, 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).
</Rainer>
Since section 7.1 indicates the optionality of timeQuality, the text in
7.1.1 needs to be written such that if you support timeQuality, then this is
way that tzKnown MUST be supported. If tzKnown is considered optional even
if timeQuality is supported, then a separate statement indicating that it
SHOULD be support should be made and the following sentences reworked to be
'if it is support...'
"The "tzKnown" parameter indicates if the original sender knows its
time zone. If it does so, the value "1" MUST be used. If the time
zone information is in doubt, the value "0" MUST be used. If the
sender knows its time zone but decides to emit time in UTC, the value
"1" MUST be used (because the time zone is known)."
<Rainer>
>
> 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 identify who is talking and in what (freeform
MSG) format.
</Rainer>
If Enterprise is equal to ACME and ACME makes two products: 1) rocket
powered roller blades and 2) electronic roadrunner traps, is this field
identifying 'acme' in both cases or is it acme.rocket or acme.trap depending
on the product? Keep in mind that both products run some of the same
software and some software unique to their own unique applications.
I suspect it is the latter, although the term enterprise is typically used
in IETF to mean the former.
<Rainer>
>
> 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?
</Rainer>
The text in question is
" Besides this risk, diagnostic message, if they occur too frequently,
can become meaningless. Common practice is to turn off diagnostic
logging if it is too verbose. This potentially removes important
diagnostic information which could aid the operator."
It doesn't really say what you are saying. Plus, intelligent filtering can
ensure the correct bits are what gets filtered out.
<Rainer>
> 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...
</Rainer>
I seem to have a very different definition of a security considerations
section than you do. I can't advise.
<Rainer>
> 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?
</Rainer>
You have not commented on 8.6.
Ok. perhaps this would help: For each of the sections ask yourself 'why is
this a security' consideration and ensure the answer gets published. Also
make sure you don't define requirements (upper or lower case).
<Rainer>
> 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 implementer that the protocol might
not be suitable for a specific application. Should I still drop it?
</Rainer>
Again, ensure the 'why this is a security consideration' is included.
<Rainer>
>
> 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.
</Rainer>
Add to draft.
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec