Advisory Board Rules on snmpinasnparseerrs

Under what conditions should that counter be incremented?

SilverCreek, the SNMP Test Suite, contains three tests for checking if an agent properly handles invalid and unexpected PDU types. These tests are 1.1.14 for SNMPv1, 2.5.1.7 for SNMPv2c and 3.5.1.7 for SNMPv3. These tests have been a source of controversy in the networking community. IWL presented the controversy to its Advisory Board and asked for a ruling.

The objective of the tests is to determine if the agent properly handles invalid and unexpected PDU types. The tests send a response PDU (tag 0xA2), a trap PDU (tag 0xA4) and an invalid PDU (tag 0x42) to the agent and then monitor if a response is sent back and whether the snmpInASNParseErrs counter (or snmpUnknownPDUHandlers if implemented) is incremented appropriately.

There are two possible outcomes expected by SilverCreek. For SNMPv1 and v2c, the agent is expected to drop the packets and for the invalid PDU, to increment snmpInASNParseErrs. SilverCreek gives a warning message if the trap and response PDUs that have been sent to the agent do not cause snmpInASNParseErrs (or snmpUnknownPDUHandlers if implemented in a multi-lingual agent) to be incremented. For the SNMPv3 test the agent is expected to utilize snmpInASNParseErrs and snmpUnknownPDUHandlers (see RFC 2572, section 4.2.2) appropriately.

Some developers believe that the response PDU and the trap PDU should NOT increment the snmpInASNParseErrs counter because those are valid, but unexpected, PDU types. Everyone agrees that the invalid PDU should increment the counter.

To increment or not increment?

There is an ambiguity in the SNMPv1 and SNMPv2c specifications. IWL believes that dropping a message without incrementing an appropriate counter is bad practice, and snmpInASNParseErrs is the most appropriate counter to use (at least prior to SNMPv3, where snmpUnknownPDUHandlers was introduced, largely to clarify this ambiguity).

Some developers propose that genErr is an error-status value that picks up all the undefined conditions. However, as an error-status value, genErr is only used if you respond to the PDU, rather than dropping it. Also, genErr is not a counter, but it does have two counters associated with it: snmpInGenErrs and snmpOutGenErrs. These two counters count the number of PDUs received or sent, respectively, with an error-status value equal to "genErr". This is somewhat useful but the two counters were made obsolete for SNMPv2c and v3. Additionally, since they are a default counters they are not that informative with respect to this specific issue.

The primary argument for incrementing snmpInASNParseErrs is: For a device that acts only as an agent, it should never expect to receive, understand, or know what to do with a trap or unsolicited response PDU. The primary argument for not incrementing snmpInASNParseErrs is: Regardless of whether it acts only as an agent, a properly formed trap or response is a valid PDU even though the packet may not supply useful information to the agent.

It is the opinion of IWL that the first argument is slightly stronger. The rationale is that if the agent is not acting in a managerial role then it will not have a parsing mechanism for trap or unsolicited response PDUs so at that point in message processing the packet should be dropped and the appropriate counter incremented. RFC 2572 (Message Processing and Dispatching for the Simple Network Management Protocol) 4.2.1 states: The version of the SNMP message is determined in an implementation-dependent manner. If the packet cannot be sufficiently parsed to determine the version of the SNMP message, then the snmpInASNParseErrs RFC 1907 counter is incremented, and the message is discarded without further processing.

The Advisory Board's decision

The SNMPv1 and v2c tests originally issued a FAILED result if the counter was not incremented for any of the three PDU types. The Advisory Board has ruled that the test should respond with a WARNING, and not a FAILURE, when an agent does not increment snmpInASNParseErrs (or snmpUnknownPDUHandlers if implemented in a multi-lingual agent) for the unexpected PDU types that are sent to the agent.

Note: The "unexpected PDU types" only increment snmpInASNParseErrs in SNMP agents which don't implement snmpUnknownPDUHandlers. If your agent is a multi-lingual implementation and SNMPv3 is supported, snmpUnknownPDUHandlers should be the correct counter to increment for SNMPv1 and v2c as well.

A WARNING result means the agent did not do something it should do (or did something it should not do) but is not necessarily in violation of the RFCs because of its behavior, where "should" may or may not carry the same weight as "SHOULD" in all caps according to RFC conventions.

What do most agents do?

Based on a survey of 17 implementations, including some agents in our lab, and some customer-supplied results, there are at least four possible behaviors that agent developers have implemented:

1. The agent drops the message and snmpInASNParseErrs is incremented.

2. The agent drops the message and snmpInASNParseErrs is NOT incremented.

3. The agent does not implement snmpInASNParseErrs at all.

4. The agent responds to the message with a noError or other error-status value.

Note: Two survey respondents did not provide information on the Invalid-PDU behavior, thus the total is 15 rather than 17.

Returning a response PDU with ANY error-status value is arguably the worst of the four behaviors: in not one of the three cases are the PDU types sent by SilverCreek requests.

To foster interoperability among developers, we would like to hear how your agent behaves. If you would like to help with our survey, send your results for each PDU type to info@iwl.com Please include the name/model of the product or the third-party agent your product is based on so that we may prevent duplicate submissions. This information will be kept strictly confidential.

© 2021 InterWorking Labs, Inc. dba IWL. ALL RIGHTS RESERVED.
Web: https://iwl.com
Phone: +1.831.460.7010
Email: info@iwl.com