OK, to summarize, here goes: 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 strictly monotonically increase (i.e., to never repeat or decrease) 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) may be used. Implementers of this method need to beware of the possibility of multiple reboots occurring within a single second. Implementers need to also beware of the year 2038 problem, which will cause the unix time to wrap in the year 2038. In yet another way, implementers 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. --- Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rainer Gerhards Sent: Monday, March 23, 2009 6:49 AM To: Chris Lonvick (clonvick) Cc: [email protected] Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits Chris, <inline> > -----Original Message----- > From: Chris Lonvick [mailto:[email protected]] > Sent: Monday, March 23, 2009 2:44 PM > To: Rainer Gerhards > Cc: [email protected]; [email protected] > Subject: RE: [Syslog] 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. > You are right - at that point I overlooked that we are not latching at 2^31-1. It does definitely not make sense to use some value right in the middle of the interval for a special case. Please disregard my suggestion. Rainer _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
