Is VACM mandatory to have in the configuration file (AgentConfig.properties)

SNMP4J
1

Hi Frank,

we are planning to use SNMP4J to build an snmp agent for our product. As a starting point, i tries running the sample agent provided by SNMP4J and i understand that the program (or SNMP4J library in general) is using properties file to load few MIBs data like SNMP COmmunity, VACM entries.
with our current vendor the configuration properties are very minimal like the agent ip address, port number and just the read/write community entries. We would like to implement the new agent with SNMP4J with as minimal as the existing configuration properteis. and i tried removing few entries from “SampleAgentConfig.properties” and when i removed all VACM related entries from the prop file, the agent is not able to process the request and i see the following exception.
java.lang.Exception: Error ‘Authorization error’ generated at: 1.3.6.1.4.1.2552.200.300.1.3.1 = Null
at org.snmp4j.agent.request.SnmpRequest$SnmpSubRequest.requestStatusChanged(SnmpRequest.java:626)
at org.snmp4j.agent.request.RequestStatus.fireRequestStatusChanged(RequestStatus.java:89)
at org.snmp4j.agent.request.RequestStatus.setErrorStatus(RequestStatus.java:52)
at org.snmp4j.agent.CommandProcessor.setAuthorizationError(CommandProcessor.java:506)
at org.snmp4j.agent.CommandProcessor.processRequest(CommandProcessor.java:379)
at org.snmp4j.agent.CommandProcessor.dispatchCommand(CommandProcessor.java:340)
at org.snmp4j.agent.CommandProcessor$Command.run(CommandProcessor.java:566)
at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:312)

with our current SNMP agent we dont have any entries related to VACM and we want to get the same experience with the new agent as well (so that it will not impact our customers).
So as far as SNM4J implmentaion is considered, is VACM data mandatory? is there any way to avoid these VACM mib so that we can have a minimal mandatory set of configuration properties.

2

VACM is mandatory in SNMP4J. But SNMPv3 is not. You can follow the rules of RFC 3584 to configure VACM to support v1/v2c only. I would not do this in any configuration with read/write access, because that approach is entirely insecure. Though it is possible.

3

Hi Frank,
Thanks for the reply.
It is understood that VACM (in config properties file for ex, “snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.2.1”, “snmp4j.agent.cfg.oid.1.3.6.1.6.3.16.1.4.1”) is mandatory in SNMP4J implementation which gives some level of security.
But again in your reply , “Though it is possible” - do you mean it is still possible in SNMP4J to skip these VACM entries( ) but is not advisable? if it is still possible to not having these in the config properties , could you please let us know how can we skip this. I understood it is not secure but we would like to give the customer the flexibility of having/not having this access security.

4

The above conclusion is wrong. First, we talk about SNMP4J-Agent and not SNMP4J. Second, a fully configured VACM is mandatory full stop. “Fully configured” means consistently configured. You cannot leave important settings unset.
What is important is defined by RFC 3415 and 3584 - to name the absolut minimum set of RFCs to be read and understood to be able to write a consistent VACM configuration.

Besides that, you do not need to configure the agent with a property file. This can be done programmatically too.

You can, however, write a consistent configuration that does not allow SNMPv3 communication with the agent (command responder) - if you need to (not recommended though).