2 Sep 2003 19:43
RE: Help needed
Gillis, John <John.Gillis <at> adc.com>
2003-09-02 17:43:48 GMT
2003-09-02 17:43:48 GMT
My 2 cents: don't reset anything like snmpEngineBoots, it may wreak havoc on third-party apps and monitoring/trending tools that are expecting monotonically increasing values. It may also cause your field service guys to get an automatic pager call. Also, most equipment vendors tightly couple the snmpEngineID/sysUpTime/snmpEngineBoots with the run-time life of the box itself, even though the snmp agent is one process of many that run on the equipment; basically, once the agent or SNMP engine goes down, many carriers view this as an equipment failure or reboot and hammer you on service-level agreements. -jg -----Original Message----- From: Uri Blumenthal [mailto:uri <at> lucent.com] Sent: Tuesday, September 02, 2003 7:54 AM To: Wijnen, Bert (Bert) Cc: srinivasan R; snmpv3 <at> lists.tislabs.com; uri <at> bell-labs.com Subject: Re: Help needed On 8/29/2003 9:28 AM, Wijnen, Bert (Bert) wrote: >>(ii) In what way changing the secret values affects the >>snmpEngineBoots value ?/ what is the relation between >>snmpEngineBoots and secret values. >> > > The idea is (I am not the best security expert here, so maybe > Uri or Russ or so can jump in) that the snmpEngineBoots is part > of the "authentication-timeliness" check and it only makes > sense if the messages are at least authenticated, so if they > have at least secuirtLevel of authNoPriv. Precisely. Doesn't make sense to consider timeliness of un-authenticated messages (for it's un-trustworthy anyway). > So my thinking is that if you reset all secreats, that starting > anew with an snmpEngineBoots at zero is OK, because any old > (captured) messages that anyone would want to replay can then > never be valid, because they would not match the MAC based on the > new secrets. Yes, it's possible and correct. However considering that (a) it's unlikely that all the secrets are reset at the same time [or within a reasonably short window], and (b) it's unclear how to keep track of all those resets at the managed box [user X changed his key twice, user Y - once, and user Z - hasn't yet] as there's no key-change-counter and it's unclear when THAT counter itself needs to be reset: I'm very hesitant to consider resetting snmpEngineBoots. I see no real need for it, and problems to address before it can be made working. >>(iii) If I reconfigure a new snmpEngineID, then the users >>already configured in the device are accessible through the >>new snmpEngineID. Am I right here ? > > Well, normally (as RECOMMENDED), the managed device keeps all > secrets in a localized form. So one would need to re-generate > the localized secrets at the managed (authoritative) engine > as well. But other than that, I think that you can indeed > re-use (or continue to use) the existing users. Existing USERS can be re-used. Existing KEYS cannot, as they are localized - at the NMS level (i.e. NMS itself determines what the localized key for user X on the managed box Y will be, and updates that key to this particular value. It's not the managed box that computes localization - except maybe for the very first time when/if the key is created from a password).