session.createLocalizedUsmUserEntry very high CPU usage.

SNMP4J
1

Using version 3.5.1, I am trying to take advantage of the DirectUserTarget following the example found at How-to implement SNMPv3 GETNEXT with SNMP4J? - SNMP4J - AGENTPP.

I have to do this because my network has devices with the same username but different passphrases. I am not the administrator of the network so I cannot change the usernames and passphrases to either be unique or all use the same.

To get around creating a USM/Session for each device/username/passphrase combination, I decided to use the DirectUserTarget. It works great but I have found that the specific method session.createLocalizedUsmUserEntry causes very high CPU usage. Almost 100% whenever it executes. I have narrowed it down to the implementation of SecurityProtocols.passwordToKey method is what is causing the issue. My assumption is it has something to do with the hashing taking place.

It’s a problem for my system because I am looping through a few thousand devices to create the DirectUserTarget for each device and while it’s looping through, the CPU usage is almost 100%. If I try to do the looping in parallel, using ForkJoinPool, I get each one of my CPUs to spike to almost 100% during the processing.

Am I missing something in the library where I could be doing something else that does not lead to this much CPU usage or am I stuck with the high CPU usage.

Thanks,

Fred

2

That is normal cryptographic effort and cannot be changed.
You should cache users if you need to reuse them later. That avoids recalculating the localized keys. But for each target you need to calculate the localized key pair at least once, that is part of the standard and cannot be optimized.
The advantage from this approach is, that when a single key pair is disclosed, it will only affect a single device.

Hope that helps anyway!

3

One additional note: Please make sure, that you do reuse the AuthenticationProtocol and PrivacyProtocol instances across DirectUserTargets because otherwise, the very CPU expensive initialisation of the protocols is done again and again.