[SNMP4J] When to call USM.removeEngineTime
Tjip Pasma
tjip.pasma at ericsson.com
Thu Jun 25 14:29:45 CEST 2009
Hi Frank
Yes im aware that System.nanotime is a java 1.5+ feature, but since Im
using that in all our snmp manager applications then i choose to modify
to improve robustness.
With regards to security then i have to disagree with you:
The most important snmp v3 security concepts is authentication and
encryption and
neither of these is compromised by the changes introduced in this fix.
engineTime/-Boots protects the agents from replay attacks, but as long
as the
agent isn't modified then the replay attack security remains the same.
Accepting time changes from a agent is a fix that is only applied on the
manager
side in my case, the alternative to this implementation would be to use
the snmp
timeout to call USM.removeEngineTime and then repeat the snmp request,
this is in
principle the same solution but less effective.
Kind Regards
Tjip
-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com]
Sent: 25. juni 2009 09:09
To: Tjip Pasma
Cc: Stath, Paul; snmp4j at agentpp.org
Subject: Re: [SNMP4J] When to call USM.removeEngineTime
Hi Tjip,
As I wrote several times on the list:
(1) SNMP4J 1.x is designed for Java 1.4, therefore System.nanoTime
cannot be used.
(2) Automatically accepting time changes from a SNMPv3 entity makes its
security concept (nearly) worthless.
You should then use SNMPv1/v2c instead.
Best regards,
Frank
Tjip Pasma wrote:
> Hi
>
> I attached my fixes, there is actually two problems fixed in these two
> files.
> 1. In UsmTimeTable.checkTime there a check to see if the agents time
> have been set backwards and if it is then this new time is being
> accepted. This is where i would fix the issue with an agent reseting
> its engineBoots.
> 2. System.currentTimeMillis is replaced with System.nanoTime in misc.
> locations,
> this makes manager robust to changes in its own OS-time.
> This fix only works for java 1.5+
>
> Its been a while since i did debugging of these issues but as far as i
> remember then you are not able to detect this issue on a snmp4j API
> level.
> The pdu request will end in a timeout just like you also have
notiched.
> (A CounterEvent is send when this happens, so you may implement a an
> event listener that uses this event, but afair this didnt provide a
> robust and easy fix of the issues faced here)
>
> BR
> Tjip
>
> PS: if your manager rarely communicates with the agents then you may
> be facing the issue of agent time that "changes"
> If your manager reference clock is deviating with 500 ppm from the
> agents reference clock then in "just" 3,5 days the time will have
> drifted 150 seconds apart between thes two systems.
> So if you are communicating with time intervals of this size then you
> may wanna check what kind of differences you have in clock system.
>
>
> -----Original Message-----
> From: Stath, Paul [mailto:PStath at axxcelera.com]
> Sent: 19. juni 2009 15:25
> To: Tjip Pasma; snmp4j at agentpp.org
> Subject: RE: [SNMP4J] When to call USM.removeEngineTime
>
> Tjip:
>
> Thanks for your prompt reply.
>
> The devices I am managing are embedded, and don't have a real-time
> clock, so I don't have to worry about changes to the system time on
> the agents.
>
> However, I would be interested in your fix, since I have considered
> this course of action myself, and it would be nice to have a sanity
check.
>
> In response to your referenced link, Frank indicates that the (latest)
> version of SNMP4J returns a Report PDU on a notInTimeWindow report.
> I'm not seeing this in the JavaDoc for SNMP4J 1.10, much less the
> latest SNMP4J back in 2008-Apr-02. (Looks like maybe v 1.21 or 1.5
> based on
> Changelog.)
>
> Frank's response:
> http://lists.agentpp.org/pipermail/snmp4j/2008-April/002833.html
>
> I'm using SNMP4J v1.9.3d, and Snmp.send() is returning like a timeout,
> (ResonseEvent.getRespone() == null) even though Wireshark shows the
> ReportPDU being returning right away.
>
> Am I missing something?
>
> -- Paul
>
>> -----Original Message-----
>> From: Tjip Pasma [mailto:tjip.pasma at ericsson.com]
>> Sent: Friday, June 19, 2009 7:08 AM
>> To: Stath, Paul; snmp4j at agentpp.org
>> Subject: RE: [SNMP4J] When to call USM.removeEngineTime
>>
>> Hi
>>
>> This is actually an interesting case, im gonna check if Im facing
>> this
>
>> same case for my system.....
>>
>> Management of engineTime / engineBoots is to my experience pretty
>> flawed, as the majority of implementations that i know of, base their
>> engineTime on their operating system time.
>> The consequence of this is that if you modify the OS-time on the
>> agent
>
>> then you may end up with an agent that you wont be able to talk to
>> with snmp v3.
>> (read more details here
>> http://lists.agentpp.org/pipermail/snmp4j/2008-April/002832.html)
>>
>> I made a fix for the above case by modifying snmp4j (in
>> UsmTimeTable.checkTime, i can send you my fix if you want) so it will
>> allow an agent to use an engineTime's with a lower value than
>> expected
>
>> by checkTime. I would suggest that you modified in a similar way to
>> allow the specific case of an engineBoots of 1. (some would claim
>> that
>
>> this violates usm security for snmp v3, however i see this as
>> increasing the robustness of snmp v3 :-)
>>
>> Best Regards
>> Tjip Pasma
>>
>>
>>
>> -----Original Message-----
>> From: snmp4j-bounces at agentpp.org
>> [mailto:snmp4j-bounces at agentpp.org] On Behalf Of Stath, Paul
>> Sent: 18. juni 2009 21:55
>> To: snmp4j at agentpp.org
>> Subject: [SNMP4J] When to call USM.removeEngineTime
>>
>> I am using snmp4J in a long running program that performs SNMP
>> management functions.
>>
>> The devices that we are managing store the value for engineBoots in
>> non-vol.
>>
>> If the device is reset to factory default (by removing the non-vol
>> files) the value for
>> msgAuthoritativeEngineBoots becomes "1" when the device is rebooted.
>>
>> If snmp4j has already discovered the values for engineBoots and
>> engineTime for this device, any further USM PDU messages return a
>> REPORT PDU indicating that the msgAuthoritativeEngineTime provided by
>> snmp4j is wrong. When this occurs, the device is unmanageable until
>> the program is restarted.
>>
>> The removeEngineTime() method of the USM object appears to address
>> this problem, if I can get it called.
>>
>> The ResposeEvent returned from Snmp.send(pdu, target) returns a null
>> value for getResponse().
>>
>> If getReponse() would return the REPORT PDU, I could call
>> removeEngineTime() and resend the PDU.
>>
>> If I'm using TableUtils, the RetrievalEvent has a
>> getReportPDU() method that returns a REPORT PDU.
>>
>> Given that I need to clear the engineTime values for an already
>> discovered agent, what are my options, and which is cleanest?
>>
>> 1) Implement my own object with a send() method that returns a
>> RetrievalEvent rather than a ResponseEvent?
>>
>> 2) Implement an AuthenticationFailureListener class that listens for
>> AuthenticationFailureEvent messages and clears the engineTimes,
>> allowing the retry in MessageDispatherImpl to retry the PDU?
>> (This would require parsing the BERInputSteam to determine the
>> specific error, and get the engineID.)
>>
>> 3) Something else?
>>
>> -- Paul Stath
>> _______________________________________________
>> 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
--
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com
More information about the SNMP4J
mailing list