Contact Us
+1.831.460.7010

What are scalar and columnar objects?
What do the built-in tests that come with SilverCreek cover?
How do I limit testing only to my enterprise MIBs?
My private MIBs do not appear in the test suite tree, why not?
Does SilverCreek Cover CERT Advisory CA-2002-03 and  US-CERT alert TA08-162A?
What if read-write objects are implemented as read-only?
Why is lexicographical ordering important?
What is non-minimal basic encoding?



Q What are scalar and columnar objects?

A In SNMP, there are two types of objects: scalar and columnar.

"Scalar" objects are objects that are not in a table such as sysDescr, sysName, etc. They must have instance ID .0 in get/set requests and responses.

"Columnar" objects are objects that are defined in a table such as ifType, ifDescr, etc. They must have meaningful instance IDs (defined by index part of
the table) in get/set requests and responses. A tool may add .0
for scalar objects but it wouldn't know what instance IDs to "add" for
columnar objects when issuing GETs.

SilverCreek relies on the end user to add .0 or other more complicated instance IDs when issuing get/set request. As a protocol test tool, this approach is
considered better to the general users of SC as they must understand what they are doing when testing SNMP using SC. As an example, if you want
to send SNMP get/set requests in command line you must know this concept.

 

 

Q What are covered in the built-in tests that come with SilverCreek?

A For comprehensive test coverage information please see doc/sc-testlist.pdf in your SilverCreek installation directory.
SilverCreek Mx are bundled with over 1000 test scripts that can generate hundreds of thousands of test cases.  In other words the total number of tests cases available in SilverCreek is not a constant number--it grows with the number of MIB implemented in the DUT. These test scripts are divided into test suites primarily according to RFC(s) tested.  They are:

1.0  RFC-1157 (SNMPv1   Tests for ALL MIBs Loaded)
2.0  RFC-190X (SNMPv2c Tests for ALL MIBs Loaded)
3.0  RFC-341x (SNMPv3   Tests for ALL MIBs Loaded)
4.0  RFC-3414 (SNMPv3   USM-MIB)
5.0  RFC-3415 (SNMPv3   VACM-MIB)
6.0  RFC-3413 (SNMPv3   SNMP Applications)
7.0  RFC-3412 (SNMPV3   MPD-MIB)     
15.0 IPv6 IP-MIB Tests(RFC4293)
16.0 IPv6 ipForwad MIB Tests(RFC4292)
17.0 IPv6 TCP-MIB Tests(RFC4022)
18.0 IPv6 UDP-MIB Tests(RFC4113)
10.0  RFC-1213 and its updates RFC2011, 2012, 2013 and 2096 (MIB-II Tests)
20.0 RMON-1 MIB Tests
21.0 RMON-II MIB Tests
50.0  RFC-2786 (Diffie-Hellman Key Change Tests)
51.0 DOCSIS OSSI-ATP
Vul1 SNMPv1 Vulnerability Tests  (ASN.1 decoding)
Vul2   SNMPv2c Vulnerability Tests (ASN.1 decoding)
Vul3  SNMPv3   Vulnerability Tests (ASN.1 decoding)

All MIBs (including additional standard and private MIBs) loaded in SilverCreek will be tested automatically when running tests in the Protocol category:
SNMPv1 Tests for all MIBs Loaded (test suite 1.0),
SNMPv2c Tests for all MIBs Loaded (test suite 2.0),
SNMPv3 Tests for all MIBs Loaded (test suite 3.0).

If the agent under test has implemented a particular MIB that has been loaded into SC then new test cases will be automatically generated for that MIB when you run these tests.

The total number of test cases that will be generated depends on 1) The number of MIBs loaded into SilverCreek, 2) The number of MIBs the agent under test has implemented. Note that in order to make sure a MIB implementation is going to be tested you must load the MIB into SilverCreek first. This is because SilverCreek needs to know the MIB definition in order to test that MIB implementation.

You can develop additional test suites and make them appear under SilverCreek "Private" test tree node on SilverCreek GUI. Often customers may need to create additional functional tests. For that you can use SilverCreek API (Tcl) to code them. For more information about this see SilverCreek Developer's Guide.

 

 

Q How do I limit testing only to my enterprise MIBs?

A By default, any MIBs (including additional standard and private MIBs) loaded in SilverCreek will be tested automatically when running tests in the Protocol category:
SNMPv1 Tests for all MIBs Loaded (test suite 1.0),
SNMPv2c Tests for all MIBs Loaded (test suite 2.0),
SNMPv3 Tests for all MIBs Loaded (test suite 3.0).

If you only want to test your private MIBs when running protocol tests (test suite 1.0, 2.0 and 3.0) you can instruct  SilverCreek to perform testing on the defined scope by using "Test->Limit Variables to Test in Protocol Test Suites".

 

 

Q Why I don't see my private MIBs appear in the test suite tree?

A When you load a new MIB into SC, there isn't going to be a new test suite that appears in the test suite tree on the GUI. The new MIBs will be tested as part of the "SNMPv1 Tests for all MIBs Loaded", "SNMPv2c Tests for all MIBs Loaded" and/or "SNMPv3 Tests for all MIBs Loaded". In other words new test cases will be automatically generated when you run these protocol tests.

You can develop additional test suites and have them to appear under SilverCreek "Private" Test node in the test suite tree. Often customers may need to create additional tests and they can use the SilverCreek API (Tcl) to develop any private tests they want to perform against their agent. Simple test cases can be generated using SilverCreek SNMPTcl script generator.

Of course the new MIB should appear in MIB browser tree after you load it into SilverCreek.

 

 

Q Does SilverCreek Cover CERT Advisory CA-2002-03 and   US-CERT alert TA08-162A?

A CERT Advisory CA-2002-03: SilverCreek Vulnerability Tests cover CERT Advisory CA-2002-03. CA-2002-03 only targets at SNMPv1, our test suite Vul1 covers that. In addition to the original CA-2002-03, we have expanded SNMP vulnerability tests to SNMPv2c and SNMPv3. Test suite Vul2 and test suite Vul3 cover vulnerability testing for SNMPv2c and v3 agents respectively.

These test suites are designed to test your agent's ability to deal with fringe or rogue packets that it may encounter while on a live network. The test suite covers SNMPv1, v2c and v3. It provides clear test description and detailed test results.  It can determine how the agent under test will respond to and deal with abnormal, malicious or rogue packets.

 

US-CERT alert TA08-162A: Authentication for SNMPv3 is done using keyed-hash message authentication code (HMAC), which is calculated using a cryptographic hash function in combination with a secret key. Implementations of SNMPv3 may allow a shortened HMAC code in the authenticator field to authenticate to an agent using a minimum HMAC of one byte. Test4.26.x in test sutie 4.0 (USMMIB) send an authenticated message with a HMAC (message authentication digest) reduced (right trim) from 11 to 1 byte.


The expected result is for the agent to drop the request and return a usmStatsWrongDigests report.

 

 

Q What if read-write objects are implemented as read-only?

A We implemented some MIB objects as read-only according to our specifications event though they are read-write by definition. SilverCreek reports failures.
Is there a way to configure SilverCreek to skip SET tests on those actual read-only objects?
And, in this case (implementing read-only instead of read-write), what is the correct return code? readonly (4) or notWritable (17)?

----------------
You can use
1) Test->Fine-tune Testing Options-->Ignore object in read-write testing...
2) Use an Agent-Capabilities MIB module. See
    Help->Help Topics->
    Configuring Agent-Capabilities

The access level and any other variation stated in the Agent Capabilities statement are honored by SilverCreek. For example,
if the original definition is "read-write", but the Agent Cap says it is implemented as "read-only" then SilverCreek will test
this object as "read-only".

You should never return readonly (4). Readonly is a status defined but should never be used by convention.

In snmpv1, you should return "noSuchName"
in snmpv2/v3, you should return "notWritable"

 

 

QWhy lexicographical ordering is important?

A The OID of the variable you retrieved from the agent via "NEXT" operation should be in lexicographical order. If they are not then MIB walk tests (test1.1.2, test2.1.2.1, and test3.1.2.1) will abort and subsequent tests could not be run. For example the following requests/responses are correct:
Request:     1.3.6.1.2.1.113.1
Response:   1.3.6.1.2.1.113.1.0

Request:     1.3.6.1.2.1.113.1
Response:   1.3.6.1.2.1.113.2.0

While the following requests/responses are incorrect:

Request:     1.3.6.1.2.1.113.11
Response:   1.3.6.1.2.1.113.2.0

Request:     1.3.6.1.2.1.113.1
Response:   1.3.6.1.2.1.111.1.0

The lexicographical order is critical for a NEXT implementation.  If lexicographical ordering isn't properly handled then you may not retrieve the objects you want in your MIBs by issuing a simple "NEXT" command and it could cause managers to get into infinite loops.

If you decide to deal with it later and continue running tests, you can check Test->Ignore Lexi Errors  to work around this issue temporarily.

 



QWhat is non-minimal basic encoding?

A The length field for some part of the message is padded with extra octets so this should normally be the length field for the entire message.

ASN.1 has two forms for encoding the length field.  A full ASN.1 sequence consists of three elements:
< tag> <length> <contents>

Where <tag> is a single octet specifying the data type, <length> is one or more octets indicating the number of octets within <contents>, which is the value associated with <tag>.

The two forms for <length> are single-octet and multi-octet forms.  The highest bit of the first length octet indicates whether it is single (0) or multi-octet (1).  If it is 0, then the remaining bits are the length themselves; otherwise, the remaining bits indicate the length of the length field.  The single-octet form is restricted to lengths from 0 to 127, since the high bit has a special purpose.  The multi-octet form is not restricted.

So, lets take a couple examples: Suppose you have an integer encoding with the value 255.  The smallest number of octets you could encode this in is 3:
   02 01 ff

Here, 02 is the tag, 01 is the length and ff is the value.  Using the multi-octet form, the "minimal encoding" is still encoded in the fewest octets possible:
   02 81 01 ff

Here, "81" indicates multi-octet form with 1 octet in the length, then the 01 following indicates 1 octet in the contents.  The "non-minimally encoded" form would add extra bytes to the length:
   02 84 00 00 00 01 ff

Now you have 3 extra 0's in the length part of the ASN.1 encoding.  This is legal, but is generally frowned upon, because the reason for the single and multi-octet forms is to encode the length field in as few octets as possible.



 

Want to Know More?

 

Return to
SilverCreek FAQ