Hi Pasi and Chris, by and large, the suggestions are fine, with one exception for the non-redundant signature blocks, where there are a couple of issues with the proposed scheme:
a) Signature blocks cannot be empty. There must have been at least one message to be signed. Syslog-sign should not be used as a heartbeat mechanism to indicate that the originator is still alive. b) It is possible that messages of successive Signature Blocks overlap in terms of the messages whose hashes they contain - for example, some implementation might want to implement some kind of "rolling" scheme in which the first block contains hashes for messages 1-10, the second for message 3-12, the third 8-17. In the end, configuration is really going to be implementation specific. I will suggest a text that proposes one parameter to configure the maximum delay that is tolerable from the time of the message with the First Message Number to the sending of the Signature Block. Thanks --- Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, February 19, 2009 3:41 AM To: Chris Lonvick (clonvick) Cc: [email protected] Subject: Re: [Syslog] Syslog-sign: Configuration parameters Chris Lonvick wrote: > It needs to be "Resend" as these are redundant. Let me give > a very simple case to show: > If we configure the sender to have: > - a Signature Block Count (CNT) of 50 > - sigRepeat=2 > - sigResendDelay=30sec > - sigResendCount=34 > then: > time Sender Collector > 0s ---syslog messages 1-50---> > 14s ---sig block for msgs 1-50---> > 44s ---syslog messages 51-60---> > 44s ---sig block for msgs 1-50---> (R1,1) > 52s ---syslog messages 61-95---> > 52s ---sig block for msgs 1-50---> (R1,2) > 60s ---syslog messages 95-100---> > 60s ---sig block for msgs 51-100---> > > > For the first 14 seconds, the device sends 50 messages and then the > Signature Block for them. Thirty seconds later, the sigResendDelay > timer trips to send the first redundant Signature Block of the first > 50 messages - shown as (R1,1). Eight seconds after that, the sender > sees that it has sent 34 messages since sending out the previous > redundant Signature Block so it sends out the second redundant > Signature Block of the first 50 messages - shown as (R1,2). Thanks for the explanation -- I think I now understood this! > I do take your point that there is nothing to kick out the initial > signature block on a slow system. Same example: > time Sender Collector > 0s ---syslog messages 1-47---> > ...eight years later, still nothing else... > > So there should be a sigMaxInterval. > > I would rewrite it as follows: > === > 6.1.2. Configuration Parameters for Signature Blocks > Perhaps we should deal with non-redundant signature blocks first, and retransmissions afterward? How about: The following parameters control how often Signature Blocks are generated (note that the maximum message length may also force generating a Signature Block; see Sections 4.2.6 and 4.2.7): sigMaxInterval = generate a new Signature Block if this many seconds have elapsed since the previous new Signature Block (not counting retransmissions). Note that this applies even when no other syslog messages have been sent since the previous Signature Block. sigMaxCount = generate a Signature Block if this many other syslog messages have been sent since the previous new Signature Block (not counting retransmissions). (Changed "send" to "generate" here) > To ensure reliably delivery (see Section 8.5), it is useful to send > the same Signature Block multiple times. This is controlled by the > "sigRepeat" parameter: > > sigRepeat = number of times a Signature Block is resent. > It is RECOMMENDED to use a value greater than 0 in particular > when the UDP transport [RFC5426] is used. > > The following parameters control how often the redundant Signature > Blocks are sent. How about: The retransmitted Signature Blocks are not sent immediately after the original transmission, but slightly later. The following parameters control when the retransmissions are done (note that these are independent of the parameters controlling when new Signature Blocks are generated): > sigResendDelay = send a redundant Signature Block if this many > seconds have elapsed since sending the original Signature > Block, or any previous redundant Signature Blocks. How about: sigResendDelay = retransmit if this many seconds have elapsed since the previous sending of this Signature Block. ("any" could refer to any Signature Block, even a new one.) > sigResendCount = send a Signature Block if this many other > syslog messages have been sent since sending the original > Signature Block, or any previous redundant Signature Blocks. How about: sigResendCount = retransmit if this many other syslog messages have been sent since the previous sending of this Signature Block. Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
