SNMP V2 & V3

W.lilakiatsakun

SNMP V2 Protocol
RFC 3416
3 types of access to management
information

Manageragent request-response
Manager-Manager request-response :
different from SNMPV1
Agent-manager unconfirmed

SNMP V2 Message Structure

SNMPV2 PDU Formats

PDU Details (1)

request-id :unique number to each

outstanding request to the same agent

error-status: a non-zero value indicates
that an exception occurred
error-index: When the error-status field
is nonzero, the error-index value
identifies the object that caused the
error

PDU Details (2)

variable-bindings: this field enables a single
operation to be applied to a group of object
instances

First element is an OID (Object Identifier)

Second element can be
Value Value associated with each object instances
unSpecified a NULL values is used in retrieval requests
NoSuchObject indicates agent does not implement the

object refered this OID

noSuchInstance indicates that this object instance does
not exist for this operation
endOfMibView indicates an attempt to reference an OID
that is beyond the end of the MIB at the agent

SNMP V2 Operations

Comparison of SNMPv1 and

SNMPv2 PDUs

Error Status Codes in responsePDU

Values in Variable Bindings

GetRequest PDU
Same as SNMPv1, it is different only the
way that responses are handled
SNMP v1 operation is atomic
SNMP v2 operation prepares variable
binding according to following rules

1 OID not match value is set to noSuchObject

2 Otherwise, but not accessible for operation
value is set to noSuchInstance
3 Otherwise, value is set to the value of variable

GetNextRequestPDU
Same as SNMPv1, it is different only the

way that responses are handled

SNMP v1 operation is atomic
SNMP v2 processes as many as possible by
the following rule
1 the next instance can be retrieved, set the
name and value in variable-bindings
2 if no lexicographic successor exists, set the
value field to endOfMibView

GetBulkRequest PDU (1)

Its purpose is to minimize the number of

protocol exchanges required to retrieve a

large amount of management information
It uses the same selection principle as the
GetNextRequest but multiple lexicographic
successor can be selected
2 additional fields
Non-repeaters the number of variables that
single successor value to be returned
Max-repetitions the number of successor
value to be returned

GetBulkRequest PDU (2)

SetRequest PDU
The structure is same as SNMPv1
SetRequest PDU for SNMPv1 and
SNMPv2 is both atomic operation

SNMPv2-Trap PDU
The format is different from SNMPv1
It uses the same format as

GetRequestPDU
Using variable bindings field to contain
sysUpTime.0
snmpTrapOID.0
- If the OBJECT clause is present in the macro
NOTIFICATION-TYPE, each variable and its
value are copied to the variable-binding

InformRequest PDU
New PDU type for SNMP
Manager to Manager operation
Response by using Response PDU

SNMPv2 MIB (1)

System Group :
include MIB for
Object
Resources
sysORlast
change
sysORTable

SNMPv2 MIB (2)

System Group of SNMPv2

SNMPv2 MIB (3)

Revised SNMP Group

SNMPv2 MIB (4)

MIB Objects Group
snmpTrap
snmpTrapOID : OID of trap or notification

currently being sent

snmpTrapEnterprise :OID of enterprise
associated with the trap currently being sent

SNMPv2 MIB (5)

snmpSet
snmpSerialNo : TestAndIncr (INTEGER

0..2147483647)
If the agent receive a set operation for this
object with value K then the value is
incremented to K+1 mod 231
If the agent receive a set operation for this
object with value not equal to K then the
operation fails with an error of inconsistentValue
To solve multiple managers using an agent

SNMPv2 MIB (6)

Interfaces Group in RFC1573 :

extension of interface Group in MIB-II

ifXTable (Extension Table)

ifStackTable (Stack Table)
ifTestTable (Test Table)
IfRcvAddressTable (Receive Address
Table)

SNMPv2 MIB (7)

ifXTable

This table contains objects that have

been added to the Interface MIB as a res
ult of the Interface Evolution effort, or re
placements for objects of the original, MI
B-II, ifTable that were deprecated becau
se the semantics of said objects have si
gnificantly changed.

SNMPv2 MIB (8)

ifStackTable

This table contains objects that define the

relationships among the sub-layers of an interface.

ifTestTable

This table contains objects that are used to

perform tests on interfaces.
This table is a generic table.
The designers of media-specific MIBs must define
exactly how this table applies to their specific MIB.

SNMPv2 MIB (9)

ifRcvAddressTable

This table contains objects that are used

to define the media-level addresses
which this interface will receive.
This table is a generic table.
The designers of media- specific MIBs
must define exactly how this table appli
es to their specific MIB.

SNMP V3
W.lilakiatsakun

SNMP v3 Goals (1)

Use existing materials as much as possible.
It is heavily based on previous work, informally known
as SNMPv2u and SNMPv2*, based in turn on
SNMPv2p.

Address the need for secure SET support, which

is considered the most important deficiency in

SNMPv1 and SNMPv2c.
Make it possible to move portions of the
architecture forward in the standards track, even
if consensus has not been reached on all pieces.
Define an architecture that allows for longevity
of the SNMP Frameworks that have been and will
be defined.

SNMP v3 Goals (2)

Keep SNMP as simple as possible.
Make it relatively inexpensive to deploy a

minimal conforming implementation.

Make it possible to upgrade portions of SNMP
as new approaches become available, without
disrupting an entire SNMP framework.
Make it possible to support features required
in large networks, but make the expense of
supporting a feature directly related to the
support of the feature.

Security Requirement (1)

Modification of Information

Some unauthorized entity may alter intransit SNMP messages generated on behalf
of an authorized principal in such a way as t
o effect unauthorized management operatio
ns, including falsifying the value of an object
.

Masquerade

Management operations not authorized for

some principal may be attempted by
assuming the identity of another principal th
at has the appropriate authorizations.

Security Requirement (2)

Message Stream Modification

Messages may be maliciously re-ordered,

delayed or replayed to an extent which is great
er than can occur through the natural operation
of a subnetwork service, in order to effect unaut
horized management operations.

Disclosure

Eavesdropping on the exchanges between

SNMP engines.
Protecting against this threat may be required
as a matter of local policy.

Not in Security requirement

Denial of Service

Indeed, such denial-of-service attacks are in

many cases indistinguishable from the type of n
etwork failures with which any viable managem
ent protocol must cope as a matter of course.

Traffic Analysis

Many traffic patterns are predictable - entities

may be managed on a regular basis by a relativ
ely small number of management stations - and
therefore there is no significant advantage affor
ded by protecting against traffic analysis.

SNMP Entity

SNMP engine
An SNMP engine provides services for sen
ding and receiving messages,
authenticating and encrypting messages,
and controlling access to managed object
s.

a Dispatcher
a Message Processing Subsystem
a Security Subsystem
an Access Control Subsystem.

Dispatcher
It allows for concurrent support of multiple

versions of SNMP messages in the SNMP engi

ne.
It does so by:

sending and receiving SNMP messages to/from the

network,
determining the version of an SNMP message and
interacting with the corresponding Message Proces
sing Model
providing an abstract interface to SNMP
applications for delivery of a PDU to an application.
providing an abstract interface for SNMP
applications that allows them to send a PDU to a re
mote SNMP entity.

Message Processing
Subsystem
The Message Processing Subsystem

is responsible for preparing messages

for sending, and extracting data from
received messages.

Security Subsytem
The Security Subsystem provides

security services such as the authenticat

ion and privacy of messages and potenti
ally contains multiple Security Models

* User-Based Security (RFC 3414)

Access Control Subsytem

The Access Control Subsystem provides
authorization services by means of one
or more (*) Access Control Models.

* View-Based Access Control (RFC 3415)

Application
There are several types of applications,
including:

Command generators, which monitor and

manipulate management data
Command responders, which provide access to
management data
Notification originators, which initiate
asynchronous messages
Notification receivers, which process
asynchronous messages, and
Proxy forwarders, which forward messages
between entities.

SNMP Manager
An SNMP entity containing one or

more command generator and/or not

ification receiver applications (along
with their associated SNMP engine) h
as traditionally been called an SNMP
manager

SNMP Traditional Manager

SNMP Agent
An SNMP entity containing one or

more command responder and/or not

ification originator applications (alon
g with their associated SNMP engine)
has traditionally been called an SNMP
agent

SNMP Traditional Agent

SNMP Process

SNMP Security Function (1)

User-based security (RFC3414)
Encryption : DES (Data Encryption
Standard) in CBC (Cipher Block Chaining)
mode
Authentication :Combine the use of a hash
function with a secret key to provide both
authentication and protection against
tampering :HMAC (Hashed Message
Authentication Codes) [RFC2104]

SNMP Security Function (2)

Protection against playback
The receiver requires that the sender include a
value in each message that is based on a counter in
the receiver.
This counter which functions as a nonce
RFC3414 for details

Access Control : VBAC (View-Based Access

Control) [RFC3415]

It Controls which network management information

can be queried and/or set by which users.
An SNMP entity retains information about access
rights and policies in a Local Configuration
Datastore (LCD)