Subject: [Syslog] WGLC -sign-20 rgerhards review

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Dec 2006 14:32:30 +0100

Hi all,

finally, I have managed to do a thourough review. I have not excessively
commented on issues that are already being discussed on list.

All in all, the document is fine work and in good shape. My issues are
mostly small nits and many of them connected to support for 3164 and
3195 (oh yes, we've almost forgotten about it...). I have one more
substential comment (actually a suggestion) at the end of the review.

While I reviewed the document I also thought how I would actually
implement syslog-sign in the two (quite different) syslog products that
I influence. I would like to express that section 7 is very helpful in
understanding the overall concept and its implications. This is an
excellent description. From the implementor's point of view, I think the
document clearly conveys what needs to be done to implement the
protocol. After reviewing, I have a clear understanding of where and
what I need to modify in our software's design to implement -sign. Of
course, there are probably some caveats that I will only detect if we
actually implement it, but that should be no major issues.

Now on to the details.

---- abstract ----
"defined in RFC 3164,"

3164 is informational, so it is "described" at most
 
[same comment for section 1. and section 3. (first paragraph)]

---- section 3. ----
##
   receiving renders the mechanism useless.  For this reason, syslog
   sender and receiver implementations implementing this specification
   MUST support messages of up to and including 2048 octets in length,
##

I didn't catch it when it was brought up on list before. I was thinking
too much of syslog-protocol. However, we must stick with a max size of
1024 because neither RFC 3164 NOR RFC 3195 allow for more. In regard to
3195 this is somewhat debatable, but arguments that more is supported
are on slippery ground.

---- section 4.1 ----
##
   There is a need to distinguish the Signature Block itself from the
   syslog message that is used to carry a Signature Block Signature
   Blocks MUST be encompassed within completely formed syslog messages.
##

I think there is a period missing "Signature Block###.### Signature
Blocks MUST ...".

--
No additional comment on APP-NAME, MSG-ID - see already existing thread

##
   Similarly, when used with traditional syslog [10], the Signature
   Block message MUST contain a valid TAG field.  The TAG field MUST
   have the value of "syslog" (without the double quotes) to signify
   that this message was generated by the syslog process.
##

I think "... was generated by the syslog process." implies a specific
software architecture (which is beyond the scope of the IETF). I would
recommend something along the lines of "that this message is an
administrative message inside the syslog protocol".

--- section 4.2. ---
The term "bytes" is used. I was advised some time ago that "octets" is
more appropriate inside the IETF.

The sample is missing the quotes around SD-PARAMs. It should read as
follows:

"[ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx"
CNT="xxx"
   HB="xxx" SIGN="xxx"]"

---- section 4.2.1 ----
" The Signature Block version field is 4 characters in length."
We must be careful. Syslog-protocol now mandates UTF-8 in this field. So
a character is not equal to an octet. I guess octet is meant. If I read
on, the term "byte" reappears. I suggest using a unified term. This
comment also applies to the sections following after 4.2.1.

--- section 4.2.3 ---
This is not something overly important... but might it be possible to
allow 999 sig groups when SG is '3'? I agree it is unlikely to have more
than 192 groups, but does it hurt to support it in (rare) cases where it
might be needed?

---- section 4.2.4 ----
I do not understand why the global block counter works across different
signature groups. Wouldn't it be more useful if it were on a
per-signature-group basis? I would appreciate if you could elaborate a
little on the reasoning.

---- section 4.2.5 ----
What happens if the (first) message number latches at 9999999999? What
is the "message number"? I did not find it defined anywhere. Of course,
I think I can guess (number of messages "sent over" this signature group
since reboot?) what it means, but it should be defined.

---- section 4.2.7 ----
size needs to be changed back to 1024 (see above for reasons)

---- section 5.2 ----

-- Bullet Point "b":

I recommend to refer the timestamp from syslog-protocol (instead of RFC
3339) because code to handle that is already present in syslog
applications.

---- section 5.3. ----
size needs to be changed back to 1024 (see above for reasons)

---- section 5.3.2.1. ----
Quotes need to be added to sample:

  "[ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TBPL="xxx"
INDEX="xxx"
   FLEN="xxx" FRAG="xxx" SIGN="xxx"]"

--- section 5.3.2.6. ---
- This comment is just in case that we will (for whatever reason) stick
with messages sizes above 1024: then, the fragment length must be 4
octets. This comment does not apply if we change back to 1024.

- registry names must be suggested to IANA

---- section 7.1 ----
bullet point "d":
##
       The resulting authenticated log file contains all messages that
       have been authenticated and implicitly indicates (by missing
       message numbers) all gaps in the authenticated messages.
##
I think it should be pointed out that "missing" messages are not
necessary actually missing. They might just have never been sent to this
collector.

See 4.2.3:
##
   One reasonable way to configure some installations is to have only
   one signature group, ...
##

The same can apply in relay chains where interim relay may not relay all
messages to the (same) final destination.

---- section 9. ----
[just for completeness - see other thread]
There are no IANA registries for APP-NAME and MSGID.

---- section 12. ----
Is Reference [4] actually necessary?

references 8, 9, 11, 13, 14, 15, 16 need to be moved to "Normative
references". Reference [12] can be dropped if my comment above is
followed.

---- GENERAL ----

- must "Note to RFC Editor" not be a separate section?

-- use of MUST --
I am not sure if "MUST" is often enough used. For example, section 4.2.1
says 

##
  As such, the version, hash algorithm and signature scheme defined in
   this document may be represented as "0111" (without the quote marks).
##
This text to me implies that another Version may be used for this
document. That, however, poses a problem on the receiver side. Should we
say it MUST be "0111" if it is to be interpreted according to this
document.

Similar comments apply to other places (e.g. 4.2.3.) where I am missing
a MUST. 

-- RFC 3195 --

Is it intentional to just support RAW profile? If so, why?

-- original syslog messages --
There is no indication or alteration to the original syslog records
(those that are signed). This is perfectly fine for SG modes 0, 1 and 2.
For SG 3 it would be useful to have an optional SD-ID for the original
messages themselves specifying the signature group. This could be
something like [signed SG="3" SPRI="xxx"]. This would be very helpful in
conveying which group the message belongs to. The sender knows this
information, because it needs to build the signature blocks and thus
must know which hash to go into which group. So there is no extra effort
here.

I came to this point while I was thinking how to implement syslog-sign.
Let me quickly explain, it might help grasp the idea behind my
suggestion.

In rsyslog, I have multiple filters that can be applied to messages.
Among them is PRI, of course, but also things like expressions inside
the MSG text itself. From the design perspective, each "forward syslog"
action is a sender in itself. I would model it so that each of these
actions will use its own signature group. So I need mode 3. The question
now is: how can the receiver tell which message belongs to which group?
The Draft intentionally does provide any guidance here. I think,
however, that stems back to the days where it was modelled for 3164 and
3195 exclusively. With -protocol, it is easy to convey that information
within STRUCTURED-DATA. It makes life on the reciever side much simpler.
I know this does not work for 3164 and 3195, but in the long term we
will have most messages formatted in -protocol format. Besides that, if
we add it as optional nothing will be hurt in all of the cases.

Does that make sense?

Rainer

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Thu, 21 Dec 2006 12:43:02 -0500

I would like to plea with the group to figure out ways to stop using the
legacy MTU as a reason to constrain new standards. I would rather see
syslog-sign not support 3164 than for it to be constrained to 1024 bytes
because of some belief that it needs to support a non-normative RFC. My
recommendation is to NOT support 3164, Fix 3195 (remove the MTU), and
don't constrain the MTU unless there is a good reason (non-normative
legacy is not a good reason). 

John Moehrke
GE Healthcare

> -----Original Message-----
> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Thursday, December 21, 2006 7:33 AM
> To: [email-masked]
> Subject: [Syslog] WGLC -sign-20 rgerhards review
> 
> Hi all,
>