[SNMP4J] V3 Not In Time Window and Client Clock Drift
Elise Atkins
eatkins at tavve.com
Mon Jun 3 21:43:03 CEST 2013
Thank you. Look forward to the new release.
Elise
Frank Fock wrote:
> 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
>>>
>>
>
More information about the SNMP4J
mailing list