Hi, why are we allowing multiple ways to set this? Since our mission is to define standards, why not standardize one way?
I think there are problems with rollover when using unix time or snmpBoots. If we simplify this to use a simple increasing value, then we avoid that complexity. dbh > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Alexander Clemm (alex) > Sent: Monday, March 23, 2009 5:51 PM > To: Rainer Gerhards; Chris Lonvick (clonvick) > Cc: [email protected] > Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits > > 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 > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
