Subject: Re: [Syslog] Syslog-sign: Configuration parameters

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 16 Mar 2009 08:57:56 -0700

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-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 19, 2009 3:41 AM
To: Chris Lonvick (clonvick)
Cc: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/syslog