Re: Syslog-sign: Last minor clarifications/nits

>>
>> SNMP, as I understand RFC3414, seems to have solved this by  
>> requiring the
>> device to actually increment the counter and store it in non- 
>> volatile memory.
>> I think this is a good compromise and would suggest the we mandate  
>> this, too,
>> except that we permit any increment as long as the resulting  
>> sequence will be
>> strictly monotonically increasing (this is necessary to permit  
>> simply copying
>> over the SNMPEngineBoots counter from the SNMP subsystem, if  
>> syslogd has
>> access to it).
>
> This sounds good.  ..I'm trying to remember if this is what was  
> first discussed for RSID when John Kelsey first proposed a counter  
> for this.

The original intent of RSID is an opaque unique value that could be  
used in a number of ways. It had no original semantics, beyond the  
obvious ones needed for a counter.

Later, you and I observed that a timer more-or-less works as it's  
monotonically increasing and thus not going to repeat. We added in the  
SNMP things in Jan 2002.

Here's text:

4.2.2.  Reboot Session ID

    ....  A Reboot Session ID is
    expected to increase whenever an originator reboots in order to  
allow
    collectors to distinguish messages and message signatures across
    reboots.  Hence, an originator needs to retain the previous Reboot
    Session ID across reboots.  .....

    If the value reaches 9999999999, then manual
    intervention may be required to subsequently reset it to 1.
    Implementors MAY wish to consider using the snmpEngineBoots value as
    a source for this counter as defined in [RFC3414].

Kelsey's solo -01 draft says in its entirety:

2.3.4 Reboot Session ID

    The reboot session ID is a 48-bit quantity encoded in base 64 as
    eight bytes, which is required to never repeat or decrease in the
    lifetime of the device.

That text remains in my -04 unaltered. In -05, the reference to  
snmpEngineBoots appears, and I remember you (Chris) and I discussing  
beforehand that it could be a timer (which meets the requirements of  
the original) or an SNMP equivalent.

I will also note that it doesn't take a lot of lawyering to note that  
there are other implementations that meet the original requirements  
including a hash or hmac with frosting and sprinkles to manage  
collisions, (or even just ignoring the collision issue, in some  
cases), a 48-bit finite field, and many other things that are more  
complex than and technologically inferior to the naive reboot counter.

I'll also note that if we went back to John's original of a 48-bit  
number in base64, then a 48-bit timestamp (truncate 64-bit time_t) is  
good enough, too.

	Jon

_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog