Unexpected behavior with default handling of AES256

Hey folks,

Thanks for all the hard work you’ve put into SNMP4J over the years!

We recently got a report that GETs and WALKs using SNMPv3 with AES256 as the privacy protocol were failing with Message processing model 3 returned error: Unsupported security level.

We discovered that when calling org.snmp4j.security.SecurityProtocols#addDefaultProtocols, AES256 gets added to the list of known protocols, but registered with a blank id. This means that it doesn’t get picked up in requests that refer to it using PrivAES256.ID.

I wonder if we should modify this block snmp4j/SecurityProtocols.java at 2.5.8 · j-white/snmp4j · GitHub (from an older version, but appears unchanged in recent releases) to also ignore empty strings in addition to null values.

Hi,

The error message “unsupported security level” means that the security protocol could be found but there is no user that with the specified security name that has sufficient keys to support the requested security level.

I guess, you misinterpreted the code you found. You are pointing to a logic that allows to use different OIDs as identifier for a protocol than defined by the protocol itself. Something you will not need, hopefully.

What SNMP4J version are you using?

Best regards,
Frank

Thanks for the response Frank.

Here’s a minimal example with SNMP4J v3.7.7:

Note the value of the key for the PrivAES256 protocol in the privProtocols map.

OK, thank for providing more details. It seems that it is a regression caused by the Java version you are using regarding interpreting the properties content and/or the content of the SecurityProtocols.properties used itself.

The properties file’a content should be:

org.snmp4j.security.AuthHMAC128SHA224
org.snmp4j.security.AuthHMAC192SHA256
org.snmp4j.security.AuthHMAC256SHA384
org.snmp4j.security.AuthHMAC384SHA512
org.snmp4j.security.PrivDES
org.snmp4j.security.Priv3DES
org.snmp4j.security.PrivAES128
org.snmp4j.security.PrivAES192
org.snmp4j.security.PrivAES256

As you can see the last line has the same structure as any line before.

To work around the issue, you can setExtensibilityEnabled to false (is faster anyway) or provide a mapping that is read correctly, for example, by explicitly providing all protocol OIDs after the equal sign by specifying the Java environment variable org.snmp4j.securityProtocols with a path to a properties file with the following content:

org.snmp4j.security.AuthHMAC128SHA224=1.3.6.1.6.3.10.1.1.4
org.snmp4j.security.AuthHMAC192SHA256=1.3.6.1.6.3.10.1.1.5
org.snmp4j.security.AuthHMAC256SHA384=1.3.6.1.6.3.10.1.1.6
org.snmp4j.security.AuthHMAC384SHA512=1.3.6.1.6.3.10.1.1.7
org.snmp4j.security.PrivDES=1.3.6.1.6.3.10.1.2.2
org.snmp4j.security.Priv3DES=1.3.6.1.6.3.10.1.2.3
org.snmp4j.security.PrivAES128=1.3.6.1.6.3.10.1.2.4
org.snmp4j.security.PrivAES192=1.3.6.1.4.1.4976.2.2.1.1.1
org.snmp4j.security.PrivAES256=1.3.6.1.4.1.4976.2.2.1.1.2