Advisory Board Rules on
SNMPv3 usmUsersSpinLock

Are SNMPv3 managers required to use usmUserSpinLock in every SET request?

SilverCreek, the SNMP Test Suite, contains a test suite for RFC3414 (the USM-MIB). There are several usmUserTable tests that send row creation SET requests to the agent under test.

The test packets used in those tests do not have usmUserSpinLock included in variable bindings. An agent is expected to pass those tests.

An engineer contacted IWL technical support to report an SNMPv3 agent implementation failing these tests. The agent under test returned an inconsistentValue error when processing a row creation SET request that does not contain usmUserSpinLock in its variable bindings.

The engineer contacted the vendor of their SNMP stack.

The vendor insisted that usmUserSpinLock must be used in any row creation SET request. The vendor referred IWL to the sample row creation procedures described on page 39 of RFC3414. Because usmUserSpinLock is used in the sample steps for row creation so they argued it must be used in any row creation SET request.

IWL explanation

usmUserSpinLock is defined as an "advisory lock". Because it is an advisory lock, SNMP managers can still read and write the usmUserTable while the table is locked. Managers are recommended to use usmUserSpinLock to avoid conflicts and the agent must check the value of usmUserSpinLock if it is included in a SET request. But this does not mean a SNMPv3 manager must use it in every SET request to update the usmUserTable.

The agent must support updating usmUserTable via SET requests that do not contain usmUserSpinLock. The agent should return the appropriate error status if conflicts do arise. Several of SilverCreek's usmUserTable row creation tests test the agent implementation intentionally using SET requests without usmUserSpinLock in the variable bindings.

The Advisory Board's decision

A compliant agent must support usmUserSpinLock. However a compliant agent should not enforce requiring usmUserSpinLock to be present in the varbind list on a row creation, but if it is in the varbind list, it must be checked for the correct value according to the semantics of usmUserSpinLock.

It is recommended that the manager include usmUserSpinLock in the varbind list but it need not be present if the manager application has good and valid reasons not to (such as a competing manager doing a DoS attack via usmUserSpinLock or some other corner case scenario).

Regarding the example steps to create rows, RFC 3414 says "it is recommended to follow this procedure". Regarding "recommended" RFC 2119 says "there may exist valid reasons in particular circumstances to ignore a particular item". If the SNMPv3 Working Group had meant that using usmUserSpinLock was required, then the word "required" would have been used.

All five members of advisory board have unanimously agreed over this mandatory-to-implement-by-agents, not mandatory-to-use-by-managers interpretation.

The SNMP Advisory Board of IWL

IWL works with technology experts from the Internet Engineering Task Force (IETF) with special expertise in networking protocols:

Andy Bierman, Consultant
Jeff Case, SNMP Research
Dave Perkins, Author of the book "Understanding SNMP MIBs"
Randy Presuhn, Consultant
Steve Waldbusser, Consultant

LEARN MORE

Advisory Board Rules on SNMPv3 usmUsersSpinLock

Are SNMPv3 managers required to use usmUserSpinLock in every SET request?

IWL explanation

The Advisory Board's decision

The SNMP Advisory Board of IWL

InterWorking Labs

Advisory Board Rules on
SNMPv3 usmUsersSpinLock