Hi, If I recall correctly, there was a possibility of replay attacks if the counter could wrap. That's why SNMP latches it. Given the 68 year timeframe, wrap shouldn't be required.
(I remember questioning whether we shouldn't wrap when this was being developed, and Marshall Rose assured me he would personally come reset my devices every 68 years if I found it problematic ;-) Dbh David Harrington [EMAIL PROTECTED] co-chair, IETF SNMPv3 WG > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 26, 2003 11:05 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: RE: Where we're at - 25 Aug 2003 > > > Hi Rainer, > > On Tue, 26 Aug 2003, Rainer Gerhards wrote: > > > > John and Jon have updated syslog-sign: > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt > > > > > > I believe that Albert suggested that more characters be added > > > to the TAG > > > field. He said that "@" would be good. Are there any others > > > that should > > > be added in Section 2.2? I'd like to get that resolved and > > > then move this > > > work along to WG Last Call and then submission to the > IESG as it is > > > looking very complete now. > > > > I am sorry to eventually come into your way, but a quick question to > > 3.4, the reboot session ID. My apologies if this already > was discussed, > > but the WG mailing lists archive search did not work and I > did not find > > a related post by browsing. > > It seems to be having toubles. :-( > > > > > -sign says, the reboot session ID mus not be automatically > reset to 0 if > > it latches at 9999999999. I agree that this is a fairly big > number. But > > think about a tool like logger. As of my understanding, each > > command-line invocation would create a new "reboot > session". Now think > > of it being used for years.... I am not sure if we would > eventually hit > > the high mark. On the other hand, it would take years to > wrap back to 0. > > So is it really that bad to allow for automatic rollover? I > am asking > > because I assume implementors would do it anyhow. Take my logger > > example: when coding this, would I really stop processing > when I hit the > > highest number? I have to admit I would implement an > automatic rollover, > > simply because I would eventually loose vital log data if I > would not do > > it - which is in my point of view worse. > > That was mostly pulled from the SNMPv3 User-based Security Model: > > ---snip--- > Whenever the local value of snmpEngineBoots has the value 2147483647 > it latches at that value and an authenticated message always causes > an notInTimeWindow authentication failure. > > In order to reset an SNMP engine whose snmpEngineBoots value has > reached the value 2147483647, manual intervention is required. > The engine must be physically visited and re-configured, either > > > > Blumenthal & Wijnen Standards Track > [Page 14] > > RFC 2574 USM for SNMPv3 > April 1999 > > > with a new snmpEngineID value, or with new secret values for the > authentication and privacy protocols of all users known to that > SNMP engine. Note that even if an SNMP engine re-boots > once a second > that it would still take approximately 68 years before the > max value > of 2147483647 would be reached. > ---/snip--- > > They chose 2147483647 because that fits nicely into a hex > value. Since we > are dealing with decimal, we could expand that. Since our > number is about > 3x larger, I figure that it should last over 200 years even > at a reboot > per second. > > I don't think that anyone has yet built a computing device with a life > expectancy of 68 years - let alone 200. :-) > > Seriously, based on that would you recommend a change? > > Thanks, > Chris > > >
