[SNMP4J] Accessing v3 servers who are ahead in time and UsmTimeTable

[Tjip Pasma]

Hi

All snmpv3 managers that i know of will keep a copy for an agent's
engineTime/engineBoots and use this information next time that the
manager is making a request towards the agent. Snmp4j saves this
information within the usm model (which is implemented as a singleton)
which fully should enable the usage scenario you describe.

The agents engineTime / engineBoots is saved in the manager together
with a the manager local timestamp (based on System.currentTimeMillis).
This information is updated everytime a response is received from agent.
Next time the manager is sending a snmpv3 request to the agent it will
calculate the correct engineTime to use based on the stored engineTime
and the difference between stored timestamp and current time.

At a glance this looks just fine, but in reality this may fail in
several different ways.
1. The speed that engineTime increases with in the agent may differ from
the speed that the managers time is increasing with. 
This is a very likely situation since these two different time systems
is based on different xtal's that is driving the time systems.
If those two xtal have a difference of 500 ppm (which is high but not
unrealistic) will cause a time difference of 1,8s within just one hour.
If your manager is running as a 24/7 service and you make snmp request
with large intervals then your system is fragile for this situation. (an
interval of more than 3.5 days will fail for a 500 ppm difference)
Solutions: 
A. let all agents / managers be based on same NTP time reference.
B. Delete engineTime / engineBoots reference in manager if you havent
made request for a longer period.

2. The engineTime used in the agents is typically based on the agents
operating system. Changing the agents system time will cause a change to
the agents engineTime.
This is a poor implementation of the engineTime but unfortunately this
is how this typically is implemented.
Adjusting the agents time forward isnt that bad, as the snmp4j manager
will recover in such case.
Adjusting the agents time backwards will however cause a severe error as
a snmp4j manager now will ignore the responses from the agent, and all
requests to the agent will now fail.
Solutions:
A. snmp4j manager should detect if an agents engineTime is adjusted
backwards and update the proxied information about this.
B. This situation isnt possible to detect on a snmp4j API level. Its
only possible to detect a timeout on the request. So whenever a timeout
is detected then engineTime / engineBoots could be deleted.

3. snmp4j and other snmpv3 managers is based on the operating system's
time to deal with enginetime calculations.
This causes similar problems as in 2)
If system time is adjusted forwards on the manager then all future
comunication with ALL snmpv3 agents will fail with a timeout.
If system time is adjusted backwards on the manager then the manager
recovers (with a "received message outside time" message)
Solutions:
A In snmp4j manager replace use of System.currentTimeMillis with
System.nanoTime if you are using java 1.5
B If communication have failed with timeout then delete engineTime /
engineBoots references for that agent.


Kind Regards
Tjip Pasma


 

-----Original Message-----
From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org] On
Behalf Of c v
Sent: 1. februar 2009 01:48
To: Jochen Katz
Cc: snmp4j at agentpp.org
Subject: Re: [SNMP4J] Accessing v3 servers who are ahead in time and
UsmTimeTable

Thanks for your quick response. If you are saying growing differences
...
the way i implemented can also be a potential issue ...  i have multiple
components in same jvm trying to send/receive  snmp requests (new snmp
instance for each component)  to same server at random times and they
can conflict too ....  as usm model is implemented as a singleton can
there be a possible conflicts in times and misbehaviour that i'm seeing
?

if that is the case ... can you suggest any implementation to work
around this?


On Sat, Jan 31, 2009 at 2:08 PM, Jochen Katz <katz at agentpp.com> wrote:

> Hello,
>
> > When trying to access servers service snmp v3 which are in time 
> > ahead (8-10 hrs) than the sender. I received a bunch of the
following messages.
> >
> > "CheckTime: received message outside time window (non authorative)"
>
> for SNMPv3 it is no problem, if manager and agent have different
times.
> But you have a problem if the times on manager and agent are growing 
> at different speeds and the difference increases by 150 seconds during

> runtime of agent and manager.
>
> If you cannot keep the host times in sync or at a stable difference, 
> your only workaround would be to regularly remove the time information

> from the USM time table. But you then lose part of the SNMPv3
security.
>
> Regards,
>  Jochen
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
>
_______________________________________________
SNMP4J mailing list
SNMP4J at agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j