Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

In the real world, using polling to implement situations where critical information needs to be

sent would be like having the emergency response service in your town call everyone every

hour to find out if they needed an ambulance or fire truck. Similarly, in SNMP, a mechanism

was needed to let an SNMP agent initiate the communication of information. This capability

was originally made part of the SNMPv1 protocol through the inclusion of the Trap-PDU

message type.

In computer science, a trap is simply a set of conditions that a device monitors continuously.

If the appropriate conditions occur, the trap is triggered and causes some sort of action to

occur. In SNMP, traps are programmed into SNMP agents, and when they are triggered, an

SNMP Trap-PDU message is sent to an SNMP Manager to inform it of the occurrence.

Examples of traps in the SNMPv1 specification include ones that trigger in the event of a

communication link failure, restart of the device, or an authentication problem.

Use of SNMP Trap and Trapv2 Messages

The communication in the case of a trap is trivial; the SNMP Agent sends the trap and the

SNMP Manager is thereby considered “informed” of what happened. That's pretty much it.

These are “Unconfirmed” messages and no reply is made back to the SNMP Agent. The

triggering of the trap may lead the network administrator to take follow-up action at the

device that sent the trap.

The designer of a particular management information base must determine what traps to

create for a particular group of objects. The implementation must specify the conditions

under which the traps will trigger, and also the destination to which the Trap-PDU message

will be sent when this occurs. In SNMPv2, the original trap notification message was

retained in the form of the Trapv2-PDU message.

Use of the SNMPv2 InformRequest Message

SNMPv2 also incorporates a second notification message type: InformRequest-PDU. This

type of message is not the same as a trap, but it is related to traps for two reasons. First,

both message types are used to communicate information without the recipient initiating the

process, and second, the two messages are sometimes used in conjunction.

The purpose of the InformRequest-PDU is actually to facilitate the communication of infor-

mation between network management stations. The SNMP Manager on one NMS can

choose to “inform” another of some piece of information by sending an InformRequest-PDU

to that other SNMP Manager. The receiving manager then replies back with a Response-

PDU to the one that sent the InformRequest-PDU, confirming receipt of the inform

message.

A common way that this message is used is to “spread the news” when a trap occurs.

Suppose a device experiences a power failure, which results in a Trapv2-PDU being sent to

NMS #1. The network administrator may want to set up NMS #1 so that receipt of particular

traps causes the information in the trap to be “forwarded” to another. The InformRequest-

PDU would be used to carry that information from NMS #1 to say, NMS #2.

Key Concept: SNMP managed devices can inform a network management station

of an important occurrence by sending it a Trap-PDU or Trapv2-PDU message.

Network administrators determine the circumstances under which one of these

messages should be transmitted. SNMPv2 adds to this capability the InformRequest-PDU

message, which can be used to propagate information about an event between

management stations.

SNMP Protocol Security Issues and Methods

In my description of the various SNMP versions, it's possible that I may have been a bit

harsh on those who worked on SNMP during the 1990s. The proliferation of many SNMP

version 2 variants really was unfortunate, and not something we often see in the world of

TCP/IP. However, now that we've seen the sort of work that SNMP does, the need for

security in the protocol would seem to be clear. Given that, and given the very low level of

security in the initial SNMPv1 protocol, it's understandable to some extent why a conflict

over security issues arose.

Why Security is Important in SNMP

The need for security in SNMP is obvious because the MIB objects being communicated

contain critical information about network devices. We don't want just anyone “snooping”

into our network to find out our IP addresses, or how long our machines have been running,

or whether our links are down, or pretty much anything else. When it comes to object write

operations using SetRequest-PDU, the concerned are magnified even more: we definitely

don't want strangers being able to control or interfere with our managed devices by issuing

bogus commands to change MIB objects that control device operation!

SNMPv1 Security

Unfortunately, the security incorporated into SNMPv1 was extremely limited; it really took

the form of only one policy and one simple technology:

☯ “Weak Objects”: SNMP was created with the mindset that the MIB objects used in

the protocol would be relatively weak. This means that the objects are designed so

that any problems in working with them result in minimal damage. The policy of the

designers of SNMP was that MIB objects that are normally read should not contain

critical information, and objects that are written should not control critical functions.

So, a read-only MIB object containing a description of a machine is fine, but one

containing the administrative password is not. Similarly, a read-write MIB object that

controls when the computer next reboots is acceptable, but one that tells the object to

reformat its hard disk is (definitely) not!

☯ Community Strings: All the devices in an SNMP network managed by a particular set

of network management stations are considered to be in a “community”. Each

SNMPv1 message sent between members of the community is identified by a

community string that appears in a field in the message header. This string is like a

simple password; any messages received with the wrong string will be rejected by the

recipient.

These security features are better than nothing, but not much. The use of weak objects is

comparable to a policy that says not to leave your car in front of the convenience store with

the doors unlocked and the key in the ignition—it is basically saying “don't ask for trouble”.

This is wise, but it’s not a complete security solution. The community strings protect against

obvious tampering in the form of unauthorized messages. However, the strings are sent in

plain open text and can easily be discovered and then used to compromise the

“community”. So this is like locking your doors when parking your car—it protects against

the casual thief but not a pro.

Of course, for some people, not leaving their car running and locking the doors when they

park are enough security, and SNMPv1's security was also sufficient for some users of

SNMP. But in newer, larger internetworks, especially ones spanning large distances or

using public carriers, SNMPv1 wasn't up to the task. This is why all that fun stuff occurred

with SNMP version 2.

SNMPv2/v3 Security Methods

During the “evolution” of SNMPv2 variants, and eventually the creation of SNMPv3, several

new security models were created to improve upon SNMPv1's security:

☯ Party-Based Security Model: This was the security model for the original SNMPv2

standard, now called SNMPv2p. A logical entity called a party is defined for communi-

cation that specifies a particular authentication protocol and a privacy (encryption)

protocol. The information is used to verify that a particular request is authentic, and to

ensure that the sender and receiver agree on how to encrypt and decrypt data.

☯ User-Based Security Model (USM): This was developed in the SNMPv2u variant and

used in SNMPv2* (SNMPv2 asterisk); it eventually was adopted in SNMPv3. The idea

here is to move away from tying security to the machines and instead use more tradi-

tional security based on access rights of a user of a machine. A variety of

authentication and encryption protocols can be used to ensure access rights are

respected and to protect message privacy. The method relies on time stamps, clock

synchronization and other techniques to protect against certain types of attacks.

☯ View-Based Access Control Model (VACM): VACM is part of SNMPv3, and defines

a method where more fine control can be placed on access to objects on a device. A

view specifies a particular set of MIB objects that can be accessed by a particular

group in a particular context. By controlling these views an administrator can manage

what information is accessed by whom.

These descriptions are “grossly simplified”, to say the least. Security is probably the most

complicated subtopic in networking, and describing these methods in detail would require

dozens and dozens of topics. You can refer to the relevant standards if you want more infor-

mation, though unless you are well-read on security topics, you will likely not be able to

make heads or tails out of what is written in them.

Use of SNMP Security Methods

Party-based security pretty much died with SNMPv2p; USM and VACM are part of SNMPv3

and provide enhanced security for those who need it (though again, it's interesting to note

how many networks continue to use SNMPv1, security warts and all.) SNMPv3 took

another important security-related step in redefining the SNMP architecture to seamlessly

support multiple security models. This enables different implementations to choose the

security model that is best for them. USM is the default model in SNMPv3.

SNMP Protocol Messaging and Message Formats

As we saw extensively in the previous section, the communication of management infor-

mation is accomplished through the exchange of SNMP messages that contain protocol

data units (PDUs). Like the messages of most TCP/IP protocols, these PDUs are designed

to use a particular field format, and are created, addressed and transported according to

specific protocol rules. SNMP messages include fields that control the operation of the

protocol, and carry a “payload” of management information in the form of Management

Information Base (MIB) objects.

In this section I describe the details of how messaging is accomplished in the SNMP

Protocol. I begin with a general discussion of issues related to message generation,

addressing and transport, and a description of how retransmission of messages is handled

when necessary. I discuss the way fields are defined in SNMP messages and describe their

general format, explaining the difference between the overall message and the PDU it

contains. I then examine the message format used in all of the important SNMP versions,

showing the structure of each message type and the fields used.

SNMP Protocol Message Generation, Addressing, Transport and

Retransmission

The section on SNMP protocol operations described the way that SNMP messages are

employed to communicate network management information. Those discussions focused

primarily on the logical processes by which different tasks are accomplished using these

messages. Let's now take a closer look at the lower-level details of exactly how these

messages are created, addressed and sent by an SNMP device.

Message generation in SNMP is a bit different than the typical TCP/IP client/server model

used for most other protocols. There aren't really any formal “clients” and “servers” in

SNMP, since management information can be obtained from any device—it is distributed.

Most of the message exchanges use a matched pair of request and reply messages. The

network management station (NMS) usually acts as the client in these exchanges, sending

a particular get or set request to an SNMP agent, which plays the role of server for the infor-

mation it contains. However, SNMP agents aren't usually considered “servers” in the

conventional sense of the term.

SNMP traps deviate from the normal request/reply model of message generation entirely.

When a trap is triggered, an SNMP agent sends a trap message to a network management

station on its own, not in reaction to receiving a request. Since trap messages are uncon-

firmed there is no reply. Note, however, that the SNMPv2/v3 InformRequest-PDU message

is confirmed, and a response message is thus sent back to the NMS that generates it.

SNMP Transport Mappings

Once a message has been generated, it is sent using the protocols at the levels below the

application layer where SNMP resides. As we saw in the overview of the SNMP Protocol,

the current SNMP standard set separates description of protocol operations and PDUs from

the methods used to actually send them. Starting with version 2, SNMP has defined several

transport mappings that describe how SNMP PDUs can be sent over a variety of internet-

working protocol suites, including TCP/IP, OSI, IPX/SPX (Novell) and Appletalk.

Many of the specific details of SNMP messaging depend on the transport mapping that is

used in a particular implementation. SNMP is of course primarily used on TCP/IP internet-

works, and TCP/IP is where our main interest lies in this part of the Guide. I will therefore

continue this discussion by looking at transport issues when SNMP is used over IP.

SNMP Message Transport Using UDP

The standard IP transport mapping for SNMP calls for it to be carried using UDP. This

decision goes back to the initial implementation of SNMPv1 (before there were distinct

transport mappings.) UDP was likely chosen because it is more efficient for the simple

request/reply messaging scheme SNMP uses; the many TCP features were not considered

necessary and add overhead that SNMP's designers wanted to avoid. It is possible that

TCP could be used to carry SNMP, defined as a different transport mapping, but I don't

believe this is actually done.

Two well-known UDP port numbers are reserved for SNMP. The first is port 161, which is

the “general-purpose” SNMP number. All devices that are set up to listen for SNMP

requests—both agents and managers—listen on port 161. Each device receives any

messages sent and replies back to the “client”, the SNMP entity that issued the request,

which uses an ephemeral port number to identify the requesting process. The second UDP

port number is 162, which is reserved for SNMP traps. Having two numbers allows regular

messages and traps to be kept separate. Normally only NMSes would listen on port 162,

since agents are not recipients of traps.

The use of UDP allows SNMP information communication to be “streamlined”, since there

is no need to establish a TCP connection, and since message headers are shorter and

processing time slightly reduced. But the use of UDP introduces a couple of issues that

SNMP implementations must be concerned with.

UDP Message Size Issues

The first issue is that of message length. SNMP PDUs can carry many MIB objects, which

means they could potentially be rather large. However, UDP is limited in the size of

message it can carry (where TCP is not). The standards specify that SNMP entities must

accept messages up to at least 484 bytes in size. They also recommend that SNMP imple-

mentations be able to accept even larger messages, up to 1472 bytes, which would

correspond to the largest size message that can be encapsulated in an Ethernet frame

(1,500 bytes, allowing 20 bytes for the IP header and 8 for the UDP header.)

The use of the GetBulkRequest-PDU message type in SNMPv2/v3 requires particular care,

since it allows a single request to result in many MIB objects being sent back in a response.

The Max Repetitions parameter must be chosen conservatively so the SNMP agent doesn't

try to send an enormous message that won't fit.

Dealing with Lost Transmissions

The second issue with UDP is the price we pay for its efficiency and simplicity: a lack of

transport features. UDP doesn't guarantee data delivery or handle retransmissions, which

means a request or reply could in theory be lost in transit. Only the device that initially

sends a request can know if there was a problem with transport—it sends the request, and

if it receives no reply knows either the request or response got lost. This puts the responsi-

bility for retransmission on the part of the device that sends the request message.

NMSes sending requests to SNMP agents generally use a timer to keep track of how much

time has elapsed since a request was sent. If the response doesn't arrive within a certain

time interval, the request is sent again. Because of how SNMP works, having a request be

received more than once accidentally will normally not cause any problems (a property

known as idempotence). The NMS does need to employ an algorithm to ensure that it does

not generate too many retransmissions and clog the network (especially since congestion

might be causing the loss of its messages in the first place.)

Handling Lost Trap Messages

Since traps are unconfirmed, there is no way for the intended recipient of a trap PDU to

know if did not arrive, nor is there any way for the sender of the trap PDU to know. This is

just a weakness in the protocol; the overall reliability of TCP/IP (and the underlying

networks) ensures that these messages are not lost very often.

Key Concept: SNMP is designed with a separately-defined set of protocol opera-

tions and transport mappings, so it can be carried over many different

internetworking technologies. The most common of these is transport mechanisms is

TCP/IP, where SNMP makes use of UDP running over IP, for its efficient and simple

communication. The lack of reliability features in UDP means that requests must be tracked

by the device sending them and retransmitted if no reply is received. The limited size of

UDP messages restricts the amount of information that can be sent in any SNMP PDU.

SNMP Message Field Definitions, General Message Format and Message

Sections

To structure its messages for transport, SNMP uses a special field format, like most

protocols. What's interesting about SNMP, however, is that its standards do not describe the

SNMP message format using a simple list of fields the way most TCP/IP standards do.

Instead, SNMP messages are defined using the same data description language (Abstract

Syntax Notation 1 or ASN.1) that is used to describe MIB objects.

The reason for this is that SNMP messages implement the various SNMP protocol opera-

tions with the ultimate goal of allowing MIB objects to be conveyed between SNMP entities.

These MIB objects become fields within the messages to be sent. The MIB objects carried

in SNMP messages are defined using ASN.1 as described in the Structure of Management

Information (SMI) standard. So it makes sense to define SNMP messages and all their

fields using the same syntax.

Since all SNMP fields are defined like MIB objects, they are like objects in that they have

certain characteristics. Specifically, each field has a name, and its contents are described

using one of the standard SMI data types. So, unlike normal message formats where each

field has just a name and a length, an SNMP message format field has a name and a

syntax, such as Integer, Octet String or IpAddress. The syntax of the field defines its length

and how it is formatted and used.

Just as regular message formats use integers to represent specific values (for example, the

numeric Opcode field in the DNS message header, which indicates the DNS message

type), this can be done in SNMP using an enumerated integer type. An example would be

the Error Status field, where a range of integer values represents different error conditions.

The decision to define SNMP messages using ASN.1 allows the message format

description to be consistent with how the objects in the format are described, which is nice.

Unfortunately, it means that the field formats are very hard to determine from the standards,

because they are not described in one place. Instead, the overall message format is

defined as a set of components; those components contain subcomponents that may be

defined elsewhere, and so on. In fact, the full message format isn't even defined in one

standard; parts are spread across several standards. So you can't look in one place and

see the whole message format.

Well, I should say that you can't if you use the standards, but you can if you look here. To

make things easier for you, I have converted these “distributed” syntax descriptions into the

same tabular field formats I use throughout the rest of this Guide. I will begin here by

describing the general format used for SNMP messages, and in the next three topics

explore the more specific formats used in each version of SNMP.

General Message Format

To understand SNMP messages, it is important that we first grasp the difference between

SNMP messages and SNMP protocol data units (PDUs). We've seen in looking at SNMP

protocol operations that the two terms are often used interchangeably. This is because

each message carries one PDU, and the PDU is the most important part of the message.

However, strictly speaking, an SNMP PDU and an SNMP message are not exactly the

same. The PDU is the actual piece of information that is being communicated between

SNMP entities. It is carried within the SNMP message along with a number of header

fields, which are used to carry identification and security information. Thus, conceptually,

the SNMP message format can be considered to have two overall sections:

☯ Message Header: Contains fields used to control how the message is processed,

including fields for implementing SNMP security.

☯ Message Body (PDU): Contains the main portion of the message. In this case, the

message body is the protocol data unit (PDU) being transmitted.

The overall SNMP message is sometimes called a wrapper for the PDU, since it encapsu-

lates the PDU and precedes it with additional fields. The distinction between the PDU and

the message format as a whole began as a formality in SNMP version 1, but became quite

important in later versions. The reason is that it allows the fields used for basic protocol

operations (which are in the PDU) to be kept separate from fields used to implement

security features. In SNMPv2, the implementation of security became a very big deal

indeed, as we will see, so this flexibility was quite important.

General PDU Format

The fields in each PDU depend on the PDU type, but can again be divided into the following

general substructure:

☯ PDU Control Fields: A set of fields that describe the PDU and communicate infor-

mation from one SNMP entity to another.

☯ PDU Variable Bindings: A set of descriptions of the MIB objects in the PDU. Each

object is described as a “binding” of a name to a value.

Each PDU will follow this general structure, which is shown in Figure 276, differing only in

the number of control fields, the number of variable bindings, and how they are used. In

theory, each PDU could have a different message format using a distinct set of control

fields, but in practice, most PDUs in a particular SNMP version use the same control fields

(though there are exceptions.)

Each variable binding describes one MIB object. The binding consists of a pair of subfields,

one specifying the name of the object in standard SNMP object identifier notation, and one

its value, formatted to match the object's SMI syntax. For example, if the object is of type

Integer, the value field would be 4 bytes wide and contain a numeric integer value. Tab le

212 describes the subfield format for each PDU variable binding.

Figure 276: SNMP General Message Format

Table 212: SNMP Variable Binding Format

Subfield

Name

Syntax

Size

(bytes)

Description

Object Name

Sequence

of Integer

Variable

Object Name: The numeric object identifier of the MIB object,

specified as a sequence of integers. For example, the object

sysLocation has the object identifier 1.3.6.1.2.1.1.6, so it would be

specified as “1 3 6 1 2 1 1 6” using ASN.1

Object Value Variable Variable

Object Value: In any type of “get” request, this subfield is a “place-

holder”; it is structured using the appropriate syntax for the object

but has no value (since the “get” request is asking for that value!)

In a “set” request (SetRequest-PDU) or in a reply message

carrying requested data (GetResponse-PDU or Response-PDU),

the value of the object is placed here.

Message Header

PDU Control Fields

PDU Variable Binding #1

Object Name

4 8 12 16 20 24 28 320

...

PDU Variable Binding #1

Object Value

PDU Variable Binding #N

Object Value

PDU Variable Binding #N

Object Name

Message Body (PDU)