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 PROTECTED] > Sent: Thursday, December 21, 2006 7:33 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] WGLC -sign-20 rgerhards review > > 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 > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
