SNMP Versions

SNMP Protocol Versions

So far, the examples we have shown in this ebook have all used the first version of the SNMP protocol which, in short form, is usually referred to as SNMPv1. In addition to SNMPv1, there are two other versions that you will commonly encounter when working with SNMP. In this chapter, we will review each version and explain their histories and purposes.

SNMPv1

Version 1 is the version that was defined in the original specification of the SNMP protocol when it was published in 1987 and it is still widely in use today.

This is quite remarkable when you consider that it predates not only the internet but pretty much the entire computing industry as we know it. To put this in context, 1987 was the year IBM introduced the PS/2 with an innovative 3.5 inch floppy disk drive, the year MSDOS 3.3 was released, and the year that "Star Trek: The Next Generation" premiered on network television.

As we've seen in previous chapters, the flexibility of the SNMP protocol was one of its original strengths and this has also contributed to its longevity.

When you first start working with a new kind of network device, we recommend that you first try scanning it using snmpwalk with version 1 and the community string "public" as seen in the following example:

                    
                    command:
                    snmpwalk -v 1 -c public 10.0.1.1
                

Many devices are configured out-of-the-box to respond to a request like this. For those that are not, they usually only require that you go to their settings to enable SNMP.

Although the designers of the original protocol ensured that it was flexible enough to work under many conditions and for many purposes, they could not think of everything in advance.

As technology evolved, two different classes of requirements emerged and subsequent versions of the SNMP protocol were released to address them. The first of these new requirements was for larger data types and the second was for security.

SNMPv2c

Version 2c of the SNMP protocol was released in 1993 and it was designed to address a limitation that became apparent as networks became faster and could support increasingly higher bandwidth rates.

In the original version of the protocol, all counters and numeric values were 32 bits in size.

Probably the most important use of counters in SNMP is to keep track of bandwidth rates on each interface. This allows networking professionals to detect which connections are under the most stress and guides not only their day-to-day operations but their long term planning as well.

Bandwidth is usually expressed in multiples of bits per second, such as kilobits per second, megabits per second, gigabits per second, etc. Under the hood though, networking equipment uses "octets" to record bandwidth. An octet is the networking equivalent of a byte in that it is composed of eight bits.

Whenever data is transmitted on a network interface, the device updates a counter adding the number of bytes transmitted to the previous value of the counter.

With counters that are 32-bits in length, this allows the device to keep track of up to 4 gigabytes of traffic. In 1987, a time when 2400 baud modems were the standard, this was an astronomical amount, but on today's fiberoptic networks that amount can be transmitted in a fraction of a second.

The 32-bit limit made it impossible to accurately measure bandwidth on newer pieces of network equipment because as soon as 4 gigabytes of traffic had passed through an interface, the counter would reset to zero.

SNMPv2c was developed to address several different issues but the counter size limit in SNMPv1 is probably the most important one. In SNMPv2c, a new counter type adds support for 64-bit counters which also have a limit but since that limit is 18,446,744,073,709,551,615 (two to the power of 64 minus 1), it safely handles the bandwidth rates of all current networks and almost anything we can currently imagine for the future.

Telling snmpget or snmpwalk to use SNMPv2c is easy. Simply use "2c" after the -v parameter instead of "1".

                    command:
                    snmpwalk -v 2c -c public 10.0.1.1
                

If your device supports SNMPv2, you'll see results that look a lot like what you get with version 1 but with the addition of new counters and values.

You might be wondering what the "c" in SNMPv2c stands for and why it is there. Around the time that the need for a new version of SNMP became clear, there were multiple competing groups each with their own take on how to address the problems emerging with the origin protocol.

During this development phase, each variant adopted a different letter so as to distinguish it from the rest, resulting in SNMPv2u, and others. In the end, SNMPv2c became the one to be widely adopted and it is the one we use now.

SNMPv3

A different set of industry changes drove the development of SNMPv3.

As you learned in Chapter 3, access to SNMP data on a device is protected by a community string. Community strings are the only security option available in SNMPv1 and SNMPv2c.

If you don't know the correct community string for a device then you can't access the data that it holds. In fact, with SNMP if you specify the wrong community string, most devices will not even reply to your request leaving you to wonder if the device is online at all.

This sounds acceptable until we dig a bit deeper and consider some real-world issues.

The first issue is that the data provided by a device using SNMP can often be sensitive in nature. It almost certainly includes IP addresses for the device and other devices on the network. It might also include locations, contact names, and firmware versions numbers which could be used to identify device vulnerabilities that could be exploited.

Many devices are configured out-of-the-box to respond to requests using the community string "public", making it easy to readily get this information but, even if you use a non-default community string, there are still risks involved.

First of all, when you make a request for SNMP using v1 or v2c, the data is sent in the clear. That means that an attacker with a protocol sniffer on your network could see all of the data that you request. Even worse, the community string itself is sent in the clear. Armed with your community string, the attacker can make their own requests to get whatever data they want.

The SNMPv3 protocol was designed with security in mind and addresses these issues.

Let's start by looking at a sample snmpwalk request that uses SNMPv3:

                    command:
                    snmpwalk -v 3 -l authPriv -u username -a SHA -A "authphrase" -x AES -X "privphrase" 10.10.60.50
                

First, you will notice that there are new command line parameters and you'll also notice that there's no -c parameter for a community string. Community strings are not used in SNMPv3. Instead, it requires a user name and a pair of passphrases which are used for authentication and to protect the request and its results.

Setting up a device to use SNMPv3 is a bit more complicated than in other versions where all you have to do is specify a community string.

First, you need to specify a user name. Along with it, you select an authentication passphrase, an authentication protocol, a privacy passphrase, and a privacy protocol.

The user name is just what it sounds like, a string identifying the user making the request.

The authentication protocol passphrase is a password that is used to validate the connection request. The authentication protocol tells snmpwalk which security technique to use to encode the passphrase in transit.

The privacy protocol tells snmpwalk how to encrypt the data that it sends and how to decrypt the response that it receives. The privacy passphrase is the password used for encryption purposes which can be, and usually is, different from the authentication passphrase.

All of these combine together to ensure that your SNMP data can be requested and received using secure techniques.

When to Use Each Version

If you have just received a new SNMP device, and you want to scan it to learn a bit about it, start with SNMPv1. It will allow you to get all the fundamental device data that you need to understand what you are dealing with.

SNMPv1 is also great for retrieving non-numeric data or counters that are expected to always have small values. Remember that the largest value a counter can have in SNMPv1 is around 4 billion. So if all you need to retrieve is the number of interfaces on a device, SNMPv1 is going to be just fine.

In some cases, you might not have a choice. Some basic devices, for example a UPS or PDU, might only support SNMPv1 because they have no requirement for the features offered by newer versions.

If you need bandwidth data then you're going to need SNMPv2c. Its support for 64-bit counters will give you the full bandwidth insight that you'll need for any modern device. Plus, with its community-based authentication, it has the benefit of being just as easy to use as SNMPv1.

If security is paramount in your organization, then there's no alternative to SNMPv3. It's more difficult to set up, it's often only available in enterprise-level networking gear, and it's more complicated to use, but it has all of the features and benefits of SNMPv2 plus top-notch security layered on top.

Next Chapter: Summary