Re: Syslog-sign: Last minor clarifications/nits

Hi Rainer,

Comments in line.

On Mon, 23 Mar 2009, Rainer Gerhards wrote:

>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Chris Lonvick
>> Sent: Sunday, March 22, 2009 11:10 PM
>> To: [email protected]
>> Cc: [email protected]
>> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
>>
>> Hi,
>>
>> There does seem to be some conflicts in the section; if it SHOULD start
>> with 1 and increment by 1 then how do we get to SnmpEngineReboots?
>
> What if we just say "must start at 1 and be strictly monotonically
> increasing"? I think this is the essence of what we need and permits any
> value to be used as seed as long as it can be assured that a higher RSID will
> be emitted later in time than a lower one. This would also permit any other
> second-counting time base reference to be used, e.g. creation/compilation
> date of the software in question.

I'm OK with most of that.  I wouldn't require it to start at "1" however. 
I'd assume that some sort of timestamp value may be used, or that if
snmpEngineBoots is used then it is already past "1".

>
> If we refer to the POSIX timestamp, I am not sure if we refer to the 32  or
> 64 Bit version of it (I even think I remember the bitness is not preciesley
> defined?). In any case, we have subtle issues: if we talk about 32 bit, the
> well-known 2038 problem is carried over to this draft. While 28 more years to
> go sound reasonable, I'd still think it is worth pointing out. With 64 Bit,
> the RSID will latch ~ 2110 when 64 bit Unix time goes beyond 9,999,999,999 -
> that is probably not a real concern ;)

I see your point but that's outside of our scope to solve.  :-)  If we 
have some verbiage in the document talking about using a time-based value 
for RSID, then at most we should have a line in the security 
considerations section telling the implementer to be aware.

>
> With any time-based counter based on seconds, there is always the subtle
> issue of two or more restarts within a single second, which means the RSID
> will not necessarily be strictly monotonically increasing. While the
> probability is (very) low for this case, it is not 0. So we cannot outrule
> it. I have not yet checked if that can lead to permanent problems (counters
> related to RSID which may occur twice).

Agreed.  Again, an implementer would have to beware of that issue if they 
chose a time-based value.

>
> 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.

>
> Also,  RFC 3414 uses 2147483647 as a special value, while we use 0. I suggest
> that we use 2147483647, too. Otherwise, a naive implementation may forget to
> convert 2147483647 to 0 when copying over the SNMPEngineBoots from the SNMP
> engine (this sounds natural to do if the syslogd has access to a SNMP
> subsystem).

I disagree on that.  2147483647 is the largest 32bit unsigned integer - 
I'm guessing that's the reason it was chosen for 3414.  If devices use a 
64bit field (or larger) to store their RSID value then they will have to 
proactively avoid using 2147483647.

Thanks,
Chris


>
> Rainer
>
>>
>> PROPOSED:
>> ===
>> 4.2.2.  Reboot Session ID
>>
>>     The Reboot Session ID is a decimal value that has a length between
>> 1
>>     and 10 octets.  The acceptable values for this are between 0 and
>>     9999999999.  Leading zeroes MUST be omitted.
>>
>>     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.  There are several ways in which
>>     this may be accomplished.  In one way, the Reboot Session ID may
>>     increase by 1, starting with a value of 1.  Note that in this case,
>> an
>>     originator is required to retain the previous Reboot Session ID
>> across
>>     reboots.  In another way, a value of the unix time (number of
>> seconds
>>     since 1 January 1970 [reference?] may be used.  In yet another way,
>>     implementors wish to consider using the snmpEngineBoots value as a
>>     source for this counter as defined in [RFC3414].
>>
>>     In cases where an originator is not able to guarantee that the
>> Reboot
>>     Session ID is always increased after a reboot, the Reboot Session
>> ID
>>     MUST always be set to a value of 0.  If the value can no longer be
>>     increased (e.g., because it reaches 9999999999), then manual
>>     intervention may be required to subsequently reset it.
>>
>>     If a reboot of an originator takes place, Signature Block messages
>>     MAY use a new PROCID.  However, Signature Block messages of the
>> same
>>     originator MUST continue to use the same APP-NAME and MSGID.
>> ===
>>
>> Does this work for everyone?
>>
>> Thanks,
>> Chris
>>
>> On Sun, 22 Mar 2009, [email protected] wrote:
>>
>>>
>>> Hi Alex,
>>>
>>> By "timestamp", at least I've meant "POSIX timestamp (seconds since
>>> 1/1/1970) when the syslog daemon started".  But even with the new
>>> text, I'm still having trouble determining whether this would be
>>> an acceptable value for RSID...
>>>
>>> Best regards,
>>> Pasi
>>>
>>>> -----Original Message-----
>>>> From: [email protected]
>>>> [mailto:[email protected]] On Behalf Of ext Alexander
>>>> Clemm (alex)
>>>> Sent: 22 March, 2009 19:06
>>>> To: Martin Schütte; [email protected]
>>>> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
>>>>
>>>> Hello Martin,
>>>>
>>>> I have clarified in the text that what I think it is you are
>>>> suggesting will be allowed.  But it is not a time stamp.  A time
>>>> stamp would be something like 2008-10-16T20:23:03+02:00.
>>>>
>>>> While it still suggests that the RSID should increase by 1, it is
>>>> not required.  It is merely required to simply increase (no problem
>>>> with an RSID reflecting a "time stamp"), unless it is set to 0.
>>>> Here is what the section in question reads now:
>>>>
>>>>    The Reboot Session ID is a decimal value that has a length
>>>>    between 1 and 10 octets.  The acceptable values for this are
>>>>    between 0 and 9999999999.  Leading zeroes MUST be omitted.
>>>>
>>>>    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.  The Reboot Session ID SHOULD
>>>>    increase by 1, starting with a value of 1.  Note that in this
>> case,
>>>>    an originator is required to retain the previous Reboot Session
>> ID
>>>>    across reboots.
>>>>
>>>>    In cases where an originator is not able to guarantee that the
>>>>    Reboot Session ID is always increased after a reboot, the Reboot
>>>>    Session ID MUST always be set to a value of 0.  If the value can
>>>>    no longer be increased (e.g., because it reaches 9999999999),
>>>>    then manual intervention may be required to subsequently reset
>>>>    it.  Implementors MAY wish to consider using the snmpEngineBoots
>>>>    value as a source for this counter as defined in [RFC3414].
>>>>
>>>> Does this accommodate your concern?
>>>> --- Alex
>>>>
>>>> -----Original Message-----
>>>> From: [email protected]
>>>> [mailto:[email protected]] On Behalf Of Martin Schütte
>>>> Sent: Thursday, March 19, 2009 1:15 PM
>>>> To: [email protected]
>>>> Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
>>>>
>>>> Alexander Clemm (alex) schrieb:
>>>>> On the first item, yes, the first item (RSID) is clearly a
>>>> counter; a
>>>>> time stamp cannot be used, nor can a value that is arbitrarily
>>>>> generated.
>>>>>
>>>>> To use a time stamp would require a parameter that is differently
>>>>> defined than the current RSID.
>>>>
>>>> Excuse my persistance here, but: why?
>>>> Especially if they do not have to be sequential.
>>>>
>>>> Is there any reason to define RSID as a counter instead of an
>>>> increasing
>>>> ID? When is a counter like 1-2-5-6 better than IDs like
>>>> 1234400000-1234500000-1234600000-12374700000?
>>>>
>>>> --
>>>> Martin
>>>> _______________________________________________
>>>> Syslog mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/syslog
>>>> _______________________________________________
>>>> Syslog mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/syslog
>>>>
>>>
>>> _______________________________________________
>>> Syslog mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/syslog
>>>
>

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