Appendix F. SNMPv3
Security has been the biggest weakness of SNMP since the beginning. Authentication in SNMP Versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a manager and agent. Any security-conscious network or system administrator knows that clear-text passwords provide no real security at all. It is trivial for someone to intercept the community string, and once he has it, he can use it to retrieve information from devices on your network, modify their configuration, and even shut them down.The Simple Network Management Protocol Version 3 (SNMPv3) addresses the security problems that have plagued both SNMPv1 and SNMPv2. For all practical purposes, security is the only issue SNMPv3 addresses; there are no other changes to the protocol. There are no new operations; SNMPv3 supports all the operations defined by Versions 1 and 2. There are several new textual conventions, but these are really just more precise ways of interpreting the datatypes that were defined in earlier versions.
This appendix provides an introduction to SNMPv3 and covers SNMPv3 configuration for a Cisco router and the Net-SNMP agent. Although SNMPv3 is not yet a full standard, a few vendors sell products with SNMPv3 support. We chose to cover two popular SNMPv3 implementations for our configuration examples.
F.1. Changes in SNMPv3
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, its developers have managed to make things look much different by introducing new textual conventions, concepts, and terminology. The changes to the terminology are so radical that it's hard to believe the new terms essentially describe the same software as the old ones, but they do. However, they do differ in terms of how they relate to each other and in that they specify much more precisely the pieces that an SNMP implementation needs.The most important change is that Version 3 abandons the notion of managers and agents. Both managers and agents are now called SNMP entities. Each entity consists of an SNMP engine and one or more SNMP applications, which are discussed in the following sections. These new concepts are important because they define an architecture, rather than simply defining a set of messages; the architecture helps to separate different pieces of the SNMP system in a way that makes a secure implementation possible. Let's look at what these concepts mean, starting with the RFCs that define them (Table F-1).
Table F-1. RFCs for SNMPv3
F.1.1. The SNMPv3 Engine
The engine is composed of four pieces: the Dispatcher, the Message Processing Subsystem, the Security Subsystem, and the Access Control Subsystem. The Dispatcher's job is to send and receive messages. It tries to determine the version of each received message (i.e., v1, v2, or v3) and, if the version is supported, hands the message off to the Message Processing Subsystem. The Dispatcher also sends SNMP messages to other entities.The Message Processing Subsystem prepares messages to be sent and extracts data from received messages. A message processing system can contain multiple message processing modules. For example, a subsystem can have modules for processing SNMPv1, SNMPv2, and SNMPv3 requests. It may also contain a module for other processing models that are yet to be defined.
The Security Subsystem provides authentication and privacy services. Authentication uses either community strings (SNMP Versions 1 and 2) or SNMPv3 user-based authentication. User-based authentication uses the MD5 or SHA algorithms to authenticate users without sending a password in the clear. The privacy service uses the DES algorithm to encrypt and decrypt SNMP messages. Currently, DES is the only algorithm used, though others may be added in the future.
The Access Control Subsystem is responsible for controlling access to MIB objects. You can control what objects a user can access as well what operations she is allowed to perform on those objects. For example, you might want to limit a user's read-write access to certain parts of the mib-2 tree, while allowing read-only access to the entire tree.
F.1.2. SNMPv3 Applications
Version 3 divides most of what we have come to think of as SNMP into a number of applications:
- Command generator
- Generates get, get-next, get-bulk, and set requests and processes the responses. This application is implemented by a Network Management Station (NMS), so it can issue queries and set requests against entities on routers, switches, Unix hosts, etc.
- Command responder
- Responds to get, get-next, get-bulk, and set requests. This application is implemented by an entity on a Cisco router or Unix host. (For Versions 1 and 2, the command responder is implemented by the SNMP agent.)
- Notification originator
- Generates SNMP traps and notifications. This application is implemented by an entity on a router or Unix host. (For Versions 1 and 2, the notification originator is part of an SNMP agent. Freestanding utilities for generating traps are also available.)
- Notification receiver
- Receives traps and inform messages. This application is implemented by an NMS.
F.1.3. What Does an Entity Look Like?
Thus far we've talked about the SNMPv3 entity in terms of abstract definitions. Figure F-1 (taken from RFC 2571) shows how the components that make up an entity fit together.
Figure F-1. SNMPv3 entity
F.1.4. SNMPv3 Textual Conventions
SNMPv3 defines a number of additional textual conventions, outlined in Table F-2.Table F-2. SNMPv3 Textual Conventions
 |  |  |
| E.2. SNMP Operations |  | F.2. Configuring SNMPv3 |
Copyright © 2002 O'Reilly & Associates. All rights reserved.