Re: Syslog-sign: Configuration parameters
Chris Lonvick <[email protected]>
| Newsgroups | gmane.ietf.syslog |
|---|---|
| Message-ID | <[email protected]> |
Hi Pasi, On Tue, 3 Feb 2009, [email protected] wrote: > > I'm still having difficulties in understanding the text in > Sections 6.1.1 and 6.1.2. > > I'll attempt to rephrase the text to one possible interpretation -- if > the original intent was something else, please propose new wording :) > > 6.1.1 Configuration Parameters for Certificate Blocks > > Certificate Blocks are always sent at the beginning of a new reboot > session. To ensure reliably delivery (see Section 8.5), it is > useful to send multiple copies. This is controlled by > "certInitialRepeat" parameter: > > certInitialRepeat = number of times each Certificate Block is > sent before the first message is sent. > > It is also useful to resend Certificate Blocks every now and then > for long-lived reboot sessions. This is controlled by the > certMaxInterval and certMaxCount parameters: > > certMaxInterval = resend the Certificate Blocks if this > many seconds have elapsed since the previous transmission. > > certMaxCount = resend the Certificate Blocks if this > many other syslog messages have been sent since the previous > transmission. > > It is desirable to allow for configuration where Certificate Blocks > are not sent at all after the first normal syslog message has been > sent. This could be expressed by setting both certMaxInterval and > certMaxCount to "0". However, it is RECOMMENDED to send > redundant Certificate Blocks even after the first message is sent > when the UDP transport [RFC5426] is used. This looks good. > > 6.1.2. Configuration Parameters for Signature Blocks > > 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 Signature Blocks > are sent (note that the maximum message length may also > force sending; see Sections 4.2.6 and 4.2.7): > > sigMaxInterval = send a Signature Block if this many seconds > have elapsed since the previous Signature Block. Note that > this applies even when no other syslog messages have been > sent since the previous Signature Block. > > sigMaxCount = send a Signature Block if this many other > syslog messages have been sent since the previous > Signature Block. > > (NOTE: the original text about sigResendDelay/sigResendCount > talks about *redundant* sendings -- the text about > sigMaxInterval/sigMaxCount above is about non-redundant > messages. I didn't quite understand what the original text > was trying to say, though...) 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). 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 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. sigResendDelay = send a redundant Signature Block if this many seconds have elapsed since sending the original Signature Block, or any previous redundant Signature Blocks. 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. sigMaxInterval = send a Signature Block if this many seconds have elapsed since the previous Signature Block was sent. Note that this applies even in the case where no other syslog messages have been sent since the previous Signature Block. As an example of these parameters in use, consider if we configure the sender to have: - a Signature Block Count (CNT) of 50 - sigRepeat=2 - sigResendDelay=30sec - sigResendCount=34 - sigMaxInterval=300sec 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---> 360s ---syslog messages 101-115---> 360s ---sig block for msgs 101-115---> 390s ---syslog messages 116-125---> 390s ---sig block for msgs 101-115---> (R2,1) 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). Three hundred seconds after that, the system has only sent 15 more messages so the sigMaxInterval timer is tripped and a signature block for them is sent. The CNT value in that Signature Block will be 15. The example continues to show that thirty seconds later the first redundant Signature Block of those 15 messages will be sent. The second will be sent within another thirty seconds. === Make sense? Best regards, Chris _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog