[SNMP4J] V3 Not In Time Window and Client Clock Drift
Frank Fock
fock at agentpp.com
Mon Jun 3 21:17:57 CEST 2013
Elise,
OK, I am convinced. I reservley checked the implementation with RFC3414 and
overseen your initial point about the order of checks.
I will provide a fix for it (ticket ID is SFJ-75).
The SNMP4J 2.2.2 release (with that fix) is then planned for next week.
Best regards,
Frank
Am 03.06.2013 17:52, schrieb Elise Atkins:
> Frank,
>
> After looking at RFC 3414, I have a different interpretation. In the
> case 1) the RFC states that the local notion of the value of the
> snmpEngineTime is to be updated to the msgAuthoritativeEngineTime.
> This should mean that the response is in time regardless of how slow
> or fast the authoritative engine's time is running as long as it moves
> in the forward direction when the time check is done in 2).
>
> b) If the extracted value of msgAuthoritativeEngineID is not the
> same as the value snmpEngineID of the processing SNMP engine
> (meaning this is not the authoritative SNMP engine), then:
>
> 1) if at least one of the following conditions is true:
>
> - the extracted value of the msgAuthoritativeEngineBoots
> field is greater than the local notion of the value of
> snmpEngineBoots; or,
>
> - the extracted value of the msgAuthoritativeEngineBoots
> field is equal to the local notion of the value of
> snmpEngineBoots, and the extracted value of
> msgAuthoritativeEngineTime field is greater than the
> value of latestReceivedEngineTime,
>
> then the LCD entry corresponding to the extracted value of
> the msgAuthoritativeEngineID field is updated, by setting:
>
> - the local notion of the value of snmpEngineBoots to the
> value of the msgAuthoritativeEngineBoots field,*
> *
> *- the local notion of the value of snmpEngineTime to the
> value of the msgAuthoritativeEngineTime field, and*
>
> - the latestReceivedEngineTime to the value of the value of
> the msgAuthoritativeEngineTime field
>
> 2) if any of the following conditions is true, then the
> message is considered to be outside of the Time Window:
>
> - the local notion of the value of snmpEngineBoots is
> 2147483647;
>
> - the value of the msgAuthoritativeEngineBoots field is
> less than the local notion of the value of
> snmpEngineBoots; or,
>
> - 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.
>
> From the above, I think if the reboots are the same and the
> msgAuthoritativeEngineTime is greater then the
> latestReceivedTimeEngineTime, the latestReceivedEngineTime should be
> updated. At that point if you fall down into 2) then the since the
>
> From release 2.1.2 UsmTimeTable starting at line 174
> if ((entry.getEngineBoots() < time.getEngineBoots()) ||
> ((entry.getEngineBoots() == time.getEngineBoots()) &&
> (time.getTimeDiff() + now >
> entry.getLatestReceivedTime() + 150)) ||
> (time.getEngineBoots() == 2147483647)) {
> if (logger.isDebugEnabled()) {
> logger.debug(
> "CheckTime: received message outside time window (non
> authoritative)");
> }
> return SnmpConstants.SNMPv3_USM_NOT_IN_TIME_WINDOW;
> }
> else {
> if ((entry.getEngineBoots() > time.getEngineBoots()) ||
> ((entry.getEngineBoots() == time.getEngineBoots()) &&
> (entry.getLatestReceivedTime() >
> time.getLatestReceivedTime()))) {
> /* time ok, update values */
> time.setEngineBoots(entry.getEngineBoots());
> time.setLatestReceivedTime(entry.getLatestReceivedTime());
> time.setTimeDiff(entry.getLatestReceivedTime() - now);
> }
>
> Frank Fock wrote:
>> Hi Elise,
>>
>> I would like to give you an update on the issue below.
>> I have checked the implementation, your findings, and the current RFC
>> 3414
>> and found out, that RFC 3414 precised the description of the incoming
>> message handling (section 3.2.7 pages 27-28).
>>
>> SNMP4J follows that description and is therefore conforming.
>> No changes will be applied.
>>
>> Could you please verify this on your side, too?
>>
>> Best regards,
>> Frank
>>
>> Am 23.05.2013 17:52, schrieb Elise Atkins:
>>> We have been successfully using snmp4j using v3 for both requests
>>> and traps but have recently run into a problem with a client whose
>>> engine time clock runs slow.
>>>
>>> Initial time synchronization goes ok and the SNMP v3 requests and
>>> responses flow properly. Eventually this client's engine time
>>> becomes more 150 seconds behind the time SNMP4j is expecting and the
>>> responses are marked as Not In Time. I have looked at RFC 2574
>>> Section 3.2 subsection 7b and the code in the UsmTimeTable class,
>>> checkTime method and have questions about the order of testing for
>>> timeliness.
>>>
>>> Based on the RFC, I would expect the code to test for the conditions
>>> in 1 first and update if needed before testing the conditions in 2
>>> but the code seems to test in the reverse order. Testing 1 and
>>> updating reboots and time first will allow the client's clock to
>>> drift (fast or slow) as long as it is always increasing and remain
>>> in the time window. Am I missing something here?
>>>
>>> Elise Atkins
>>>
>>> The RFC says:
>>>
>>> 3.2. Processing an Incoming SNMP Message
>>> 7) If the securityLevel indicates an authenticated message, then
>>> the local values of snmpEngineBoots, snmpEngineTime
>>> and latestReceivedEngineTime
>>> corresponding to the value of the msgAuthoritativeEngineID
>>> field are extracted from the Local Configuration Datastore.
>>>
>>> b) If the extracted value of msgAuthoritativeEngineID is not the
>>> same as the value snmpEngineID of the processing SNMP engine
>>> (meaning this is not the authoritative SNMP engine), then:
>>>
>>> 1) if at least one of the following conditions is true:
>>>
>>> - the extracted value of the msgAuthoritativeEngineBoots
>>> field is greater than the local notion of the value of
>>> snmpEngineBoots; or,
>>>
>>> - the extracted value of the msgAuthoritativeEngineBoots
>>> field is equal to the local notion of the value of
>>> snmpEngineBoots, and the extracted value of
>>> msgAuthoritativeEngineTime field is greater than the
>>> value of latestReceivedEngineTime,
>>>
>>> then the LCD entry corresponding to the extracted value
>>> of the msgAuthoritativeEngineID field is updated, by
>>> setting:
>>>
>>> - the local notion of the value of snmpEngineBoots to
>>> the value of the msgAuthoritativeEngineBoots field,
>>> - the local notion of the value of snmpEngineTime to
>>> the value of the msgAuthoritativeEngineTime field,
>>> and
>>> - the latestReceivedEngineTime to the value of the
>>> value of the msgAuthoritativeEngineTime field.
>>>
>>> 2) if any of the following conditions is true, then the
>>> message is considered to be outside of the Time Window:
>>>
>>> - the local notion of the value of snmpEngineBoots is
>>> 2147483647;
>>>
>>> - the value of the msgAuthoritativeEngineBoots field is
>>> less than the local notion of the value of
>>> snmpEngineBoots; or,
>>>
>>> - 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.
>>>
>>> If the message is considered to be outside of the Time
>>> Window then an error indication (notInTimeWindow) is
>>> returned to the calling module.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> SNMP4J mailing list
>>> SNMP4J at agentpp.org
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>
>
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
More information about the SNMP4J
mailing list