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
