Hi,
>> Of course, the root cause (not incrementing the engine boots in the
>> agent) is a bug in the agent, but there is a discussion going on in our
>> team now what the proper behaviour of the manager should be.
well, print out the SNMPv3 RFCs and send them to the developers of the
agent ;-)
>> The
>> discussion is whether in such cases, since we are the non-authoritative
>> engine in this exchange, the manager (and thus SNMP4J in this case)
>> should automatically do a rediscovery of the engine boots/engine time.
This should never be done automatically by SNMP4J, because the time
information is part of the security concept.
> Well, I suppose what is applicable here is section 3.2 point 7b of RFC
> 3414, but the question is: does this then also apply to the receiving of
> the report from the authoritative engine that says that the sent message
> is outside the time window? It could be argued that in this case the
> manager should attempt to resynchronize with the agent.
The relevant part is:
2) if any of the following conditions is true, then the
message is considered to be outside of the Time Window:
...
- the value of the msgAuthoritativeEngineBoots field is
equal to the local notion of the value of snmpEngineBoots
and the value of the msgAuthoritativeEngineTime field is
more than 150 seconds less than the local notion of the
value of snmpEngineTime.
...
---> Note that this means that a too old (possibly replayed)
message has been detected and is deemed unauthentic.
> This is never resolved, unless we force a cleanup in SNMP4J
> of the timing information for that agent.
This is a possible temporary solution until the agent has been fixed,
but please enable this behaviour only for the engine id of the buggy agent.
Regards,
Jochen