RE: Help needed

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).