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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.