You are on page 1of 185

Simple Network

Management Protocol
Vinay Avasthi

© Vinay Avasthi
SNMP Origin and Evolution
l SNMP evolved from simple gateway management protocol
(SGMP)

l SNMP was approved by Internet Architecture Board (IAB) as


a short term solution in 1988

© Vinay Avasthi
Following RFCs define SNMP
related standards
l RFC 1155

l RFC 1213

l RFC 1157

l There are some more RFCs that define extensions to these


RFCc

l http://www.ietf.org

© Vinay Avasthi
Network Management Architecture
l Following key concepts are used
l Management station
l Management agent
l Management information base or MIB
l Network management protocol

© Vinay Avasthi
Management Station
l It is also know as manager

l Serves as a human network manager interface into network


management system

© Vinay Avasthi
Management Station
l Management station has
l A set of applications for data analysis, fault recovery
l An interface to monitor and control the network
l A capability of translating network manager’s requirements into
the actual monitoring and control of network elements
l A database of information extracted from managed entities in
the network

© Vinay Avasthi
Management Agent
l Also know as agent

l It responds to requests for information and actions from the


manager

l Also asynchronously provides important but unsolicited


information to manager

© Vinay Avasthi
Management Information Base or
MIB
l MIB is a collection of access points at the agent for the
management station

l Manager performs monitoring function by retrieving value of


MIB objects

l Manager performs control function by setting value of MIB


objects

© Vinay Avasthi
Network management protocol
l The protocol used is SNMP or simple network management
protocol

l SNMP was designed to be an application level protocol that is


part of the TCP/IP protocol suite

l It operates over UDP

© Vinay Avasthi
Architecture
User processes of SNMPAgent process
Manager processes User processes
FTP and other SNMP SNMP FTP & other
TCP UDP UDP TCP
IP IP
Physical Layer Physical Layer

Intern
et

© Vinay Avasthi
Application Manages objects

Role of Application
Management SNMP Agent Application
GetNextRequest

GetResponse
GetNextRequest
GetResponse

SNMP Messages
GetRequest

GetRequest
SetRequest

SetRequest

Trap
Trap

Manager Agent
UDP UDP
IP IP
Physical Layer Physical Layer

Physical Datagram Exchange

© Vinay Avasthi
Proxies
l Use of SNMP requires that all agents and managers support a
common protocol suite

l To accommodate devices that do not support SNMP, concept


of proxy was developed
l A SNMP agent acts as a proxy for one or more other devices
l SNMP agent acts on behalf of proxied devices

© Vinay Avasthi
Proxies

Proxied
Manager Proxy Agent
Device

SNMP Proprietary

© Vinay Avasthi
MIB Structure
l All managed objects in SNMP environment are arranged in a
hierarchical or tree structure
l The leaf objects of the tree are actual managed objects
l Each object has a identifier of ASN.1 type OBJECT IDENTIFIER
l The identifier serves to name the object

© Vinay Avasthi
Mib-II object groups sample
iso(1)

org(3)

dod(6)
internet(
1)
directory
(1)

mgmt(2)

mib-II(1)
system(1
)
interface
s(2)

at(3)

ip(4)

icmp(5)

tcp(6)

udp(7)

egp(8)

transmis
sion(10)
SNMP(1
1)
private(4
© Vinay Avasthi
)
Mib-II object groups sample
lIf there exists an object tcpConnTable
under node tcp with identifier 13 then
identifier for tcpConnTable will be as
follows

iso org dod internet mgmt mib-2 tcp tcpConnTable


1 3 6 1 2 1 6 13

The identifier will be normally written as .1.3.6.1.2.1.6.13

© Vinay Avasthi
ASN.1
l ASN.1 stands for abstract syntax notation one
l CCITT standard x.208 defines it

© Vinay Avasthi
ASN.1 types
l Universal Types
l integer
l octetstring
l null
l object identifier
l sequence
l sequence-of
l

© Vinay Avasthi
ASN.1 types
lApplication wide types
l networkaddress — defined to allow selection of
an address from one of a number of protocol
families. Currently only supported address is
ipaddress
l ipaddress — 32 bit address using the format
specified in IP
l counter — non negative number that can be
incremented but not decremented. Range 0 to
32 -1
© Vinay Avasthi 2
ASN.1 types
lApplication wide types continued
l gauge — non negative number that may
increase and decrease, with a maximum value
of 232 -1. Once it reaches the maximum value it
latches on to that value until reset
l timeticks — non negative integer counts the
time in hundredth of a second since some
epoch
l opaque — has capability to pass arbitrary data.

© Vinay Avasthi The data is coded as OCTET STRING on


SNMP v1 — Basic concepts
l Only operation supported in SNMP are the alteration and
inspection of variables

l It is not possible to change the structure of a MIB by adding


or deleting object instances

l It is also not possible to issue commands for an action to be


performed

© Vinay Avasthi
SNMP v1 — Basic concepts
l It is also not possible to access an entire table or a row of a
table with one atomic action
l Following operations are supported
l Get
l Set
l GetNext
l Trap

© Vinay Avasthi
SNMP v1 — Authentication
l Due to many to many relationship between agents and
managers, agent needs to control use of its MIB by many
managers
l Authentication service
l Access policy
l Proxy service

© Vinay Avasthi
Authentication service
l Authentication service ensures that a communication is
authentic
l Community name is included in every message that acts as a
password and the message is assumed to be authentic if the
manager knows the password

© Vinay Avasthi
Access policy
l Access policy limits access to its MIB to a selected set of
mangers
l Different MIB views may be defined for each community
l An access mode (READ-ONLY, READ-WRITE) is defined for each
community
l The combination of MIB view and access mode is referred to as
SNMP community profile

© Vinay Avasthi
Access
MIB Access policy — Access
SNMPMode

Access Mode
READ-ONLY READ_WRITE

Category
Available for get and trap
read-only operation
Available for get and trap Available for get, set,
read-write operation operation
Available for get, set,
Available for get and trap operation, but the va
operation, but the value is implementation spec
write-only implementation specific and trap operations

© Vinay Avasthi
Proxy service
l Since proxies are created for foreign devices, these devices
maintain a SNMP access policy.

l Community concept is also useful in maintaining this policy.

© Vinay Avasthi
Object instance identification
l Scalar objects
l There is only one instance of each scalar object type
l The object identifier is concatenated with 0 for scalar type

© Vinay Avasthi
Object instance identification
l Columnar objects
l The convention used to identify these objects is to concatenate
values of scalar object identifier with INDEX objects

© Vinay Avasthi
Object instance identification
l INDEX object instance can have following values
l Integer valued

l String valued — fixed length

l String valued — variable length

l Object identifier valued

l Ipaddress valued

© Vinay Avasthi
SNMP Message
SNMP formats
Version Community SNMP PDU

Get Request PDU/GetNextRequestPDU and SetRequestPDU


PDU type Request id 0 0 Variable bindings

GetResponsePDU
PDU type Request id Error_status Error_index Variable bindings

TrapPDU
PDU type enterprise Agent_addr Generic_trap Specific_trap Time stamp Variable bindings

Variable bindings
name1 value1 name2 value2 name3 …….. namen valuen

© Vinay Avasthi
SNMP Message terms
version SNMP version
community Community string.
request_id unique identifier for all the requests that are pending
indicates that an exception has occurred noError(0), tooBig
error-status noSuchName(2), badValue(3), readOnly(4), genErr(5)
when error-status is non-zero, this indicates which of the va
error-index the exception
A list of variable names and corresponding values. In some
variable bindings fields may be null
enterprise Type of object generating trap. Based on sysObjectID
agent-addr Address of object generating trap
Generic trap type, coldStart(0), warmStart(1), linkDown(2),
generic-trap
© Vinay Avasthi
authentication-Failure(4), egpNeighborLoss(5), enterprise-S
specific-trap Specific trap code
Transmission of SNMP Message
l PDU is constructed using ASN.1 structure

l PDU is passed on to authentication service with destination


address and community name
l Authentication service performs required transformation such as
encryption

© Vinay Avasthi
Transmission of SNMP Message
l Protocol entity constructs message consisting of version field
and community name

l ASN.1 object are encoded using basic encoding rules (BER)

l In practice, authentication is typically not invoked.

© Vinay Avasthi
Receipt of SNMP Message
l SNMP entity performs receives the message

l Performs basic syntax check

l Verifies the version number

© Vinay Avasthi
Receipt of SNMP message
l Passes the user name, PDU, source address, and destination
address to authentication service
l If authentication fails a trap is generated
l If authentication succeeds, authentication service returns PDU
in the form of an ASN.1 object

© Vinay Avasthi
Receipt of SNMP message
lProtocol entity performs the basic syntax
check
l Discards the PDU if it fails to parse
l If succeeds, using the community name
appropriate SNMP access policy is selected
and PDU is processed
lIn practice, the authentication service
merely verifies that the community name
authorizes the receipt of message from
© Vinay Avasthi
GetRequestPDU
lThis message is sent by the manager to agent
for getting value(s)
lPDU type indicates that it is a GetRequestPDU
lSending entity assigns numbers so that each
outstanding request to the agent is uniquely
identified. request_id is used for this purpose.
lVariable binding contains object identifier for
Get operation
© Vinay Avasthi
GetRequestPDU
l Receiving entity responds with GetResponsePDU containing
the same request_id
l The response PDU contains the value for the object identifier
provided
l GetRequest is an atomic operation, hence either all the
variables are returned or no variable is returned

© Vinay Avasthi
GetNextRequestPDU
lThis message is sent by the manager to agent
for getting value(s)
lPDU type indicates that it is a
GetNextRequestPDU
lSending entity assigns numbers so that each
outstanding request to the agent is uniquely
identified. request_id is used for this purpose.
lVariable binding contains object identifier for
GetNext operation
© Vinay Avasthi
GetNextRequestPDU
lReceiving entity responds with
GetResponsePDU containing the same
request_id
lResponse PDU contains the value of next
object identifier in lexicographical order
l Lexicographical order is depth-first-search allowing
manager to discover the structure of MIB
dynamically
lGetRequest is an atomic operation, hence
either all the variables are returned or no
© Vinay Avasthi
SetRequestPDU
lThis message is sent by the manager to agent
for setting value(s)
lPDU type indicates that it is a SetRequestPDU
lSending entity assigns numbers so that each
outstanding request to the agent is uniquely
identified. request_id is used for this purpose.
lVariable bindings contain object identifiers and
their values to be set
© Vinay Avasthi
SetRequestPDU
l Receiving entity responds with GetResponsePDU containing
the same request_id

l The response PDU contains original variable bindings.

l SetRequest is an atomic operation hence either all the values


are set or none are set.

© Vinay Avasthi
TrapPDU
l This is an asynchronous message that an agent can sent to
manager to notify some anomaly

l PDU type indicates that it is a TrapPDU

l Unlike Get, GetNext, and Set, TrapPDU does not elicit a


response from other entity

© Vinay Avasthi
Identifying attributes
TrapPDU — identifying fields
identifies nmsubsystemthat generated trap. I
enterprise same as sysObjectID in MIB-II
agent-addr IP address of agent
generic-trap contains one of the pre-defined trap types
specific-trap indicates more specifically the nature of trap
generic trap contains one of the followingvalues —coldStart(0),
warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4),
egpNeighbourLoss(5), enterpriseSpecific(6)

© Vinay Avasthi
SNMP protocol level details
l SNMP is mostly implemented within TCP/IP architecture using
UDP protocol
l It is also possible to support SNMP within OSI architecture using
CLTS, i.e. connection less transport service

l UDP segments are transmitted in IP Datagram

© Vinay Avasthi
SNMP protocol level details
l In case of UDP two port numbers are assigned to SNMP
l Agents listen on 161 for setRequest, getRequest, and
getNextRequest
l Managers listen on 162 for traps

© Vinay Avasthi
SNMP protocol level details
l In case of CLTS two transport service access points (TSAP)
identifiers or selector are assigned
l TSAP selector SNMP is used for getRequest, getNextRequest,
setRequest
l TSAP selector SNMP-trap is used for receiving traps

© Vinay Avasthi
SNMP protocol level details
l Since both the UDP and CLTS are un-reliable, a SNMP
message could be lost
l The action to be taken upon detecting loss of a SNMP message
is not covered in standard
l The general resolution is to retry after a certain time-out period

© Vinay Avasthi
Limitations of SNMPv1
l SNMP is not suitable for management of truly large networks
because of performance limitation on polling
l You need to send one packet out to get back one packet of
information

l SNMP is not suitable to receive large volume of data


l SNMP traps are unacknowledged

© Vinay Avasthi
Limitations of SNMPv1
lVery trivial authentication is called for.
l Basic SNMP is better suited for monitoring than
control
lSNMP does not directly support imperative
commands
l One way to achieve this is to write an agent
that, on setting of a value performs some
action
lSNMP does not support manager to
© Vinay Avasthi
SNMPv2
l In July 1992, it was felt in internet community that it was
highly desirable to enable users and vendors to make a
single transition from SNMP to a second generation SNMP
l This transition standard was called SNMPv2. The original
standard was renamed to SNMPv1

© Vinay Avasthi
SNMPv2 RFCs
l Following RFCs provided enhancements necessary for
SNMPv1 transition to SNMPv2
l 1901 to 1908

l SNMPv2 can support both highly centralized as well as


distributed management strategies.

© Vinay Avasthi
SNMPv2 — key enhancements
l Structure of management information

l Manager to manager capability

l Protocol operations

© Vinay Avasthi
SNMPv2 — structure of
management information
l SNMPv2 SMI is a superset of SNMPv1 SMI

l Introduces four key concepts


l Object definitions
l Conceptual tables
l Notification definitions
l Information modules

© Vinay Avasthi
SNMPv2 — SMI — object definitions
l Object definitions in SNMPv2 — SMI are used to describe
managed objects
l Attributes for object definition
l Data Types
l UnitsPart
l MAX-ACCESS
l STATUS
l Other

© Vinay Avasthi
SNMPv2 — SMI — object definitions
— Data types
l Integer (-231 to 231 -1)
l Octetstring (size(0..65535))
l OBJECT IDENTIFIER
l Ipaddress — 32 bit address using the format specified in IP
l Counter32 — non negative number that can be incremented
but not decremented. Range 0 to 232 -1

© Vinay Avasthi
SNMPv2 — SMI — object definitions
— Data types
lCounter64 — non negative number that can
be incremented but not decremented.
Range 0 to 264 -1
lUnsigned32 — non negative number with a
maximum value of 232 -1. This type is also
used for gauge32
lGauge32 — non negative number that may
increase and decrease, with a maximum
value of 232 -1. Once it reaches the
maximum value it latches on to that value
© Vinay Avasthi
SNMPv2 — SMI — object definitions
— Data types
l TimeTicks — non negative integer counts the time in
hundredth of a second between two epochs. The definition
of object types defines two epochs

l Opaque — for backward compatibility with SNMPv1

l BITS — this is an enumeration for bits

© Vinay Avasthi
SNMPv2 — SMI — object
definitions — Data types
Range Enumeration Size
lFor SNMPv2 data INTEGER
types range Integer32
Unsigned32
refinement can OCTET STRING
OBJECT IDENTIFIER
be done BITS
IpAddress
Counter32
Counter64
Gauge32
TimeTicks
Range of permitted values may be refined by cha
and upper bounds
The enumeration of named values may be refine
removing one or more named values
The size in characters of the value may be refined
changing the lower and upper bounds
© Vinay Avasthi The repertoire of characters in the value may be
further subtyping
SNMPv2 — SMI — object definitions
— UnitsPart
l All SNMPv2 OBJECT-TYPE macros include an optional UNITS
clause that contain a textual description of the units
associated with the measurement
l Useful for any object that represents a measurement in some
kind of unit such as time

© Vinay Avasthi
SNMPv2 — SMI — object
definitions — MAX-ACCESS
lSimilar to ACCESS clause in SNMPv1
l Does not include write-only
l Includes a new categories read-create and
accessible-for-notify

MAX-ACCESS Description
not-accessible Not accessible by the manager for any operat
accessible-for-notify Only accessible via a notification
read-only read access
read-write read and write access
read-create read, write and create access
© Vinay Avasthi
SNMPv2 — SMI — object definitions
— STATUS
l STATUS mandatory clause indicates whether this definition is
current or historic.
l Object with STATUS current is valid for current standard
l Object with STATUS obsolete should not be implemented

© Vinay Avasthi
SNMPv2 — SMI — object definitions
— Other
l ReferPart is an optional textual cross reference to an object
defined in some other MIB module

l DefValPart is an optional clause that defines an acceptable


default value for a newly created object instance

l IndexPart is used in table definitions

© Vinay Avasthi
SNMPv2 Tables
l IN SNMPv2, complex management information can be
represented as table
l A table has zero or more rows
l Each of the rows contain one or more scalar objects

© Vinay Avasthi
SNMPv2 table definition
lTables are defined as a combination of rows
lA conceptual table has a SYNTAX clause of the
form
l SEQUENCE OF <entry>
l Where entry is subordinate conceptual row
lA conceptual row has a SYNTAX clause of the
form
l SEQUENCE { <type1>,…,<typeN> }
l Where there is one type for each columnar object
l Syntax has the value of that object’s SYNTAX clause
l All columnar objects are always present
l DEFAULT and OPTIONAL clauses are not allowed in
© Vinay Avasthi
SEQUENCE definition
SNMPv2 table definition
l Each columnar object is defined in the usual manner with
OBJECT-TYPE MACRO

© Vinay Avasthi
SNMPv2 table definition
l Two types of tables are allowed in SNMPv2
l Tables that prohibit row creation and deletion by a manager
l Tables that allow row creation and deletion by a manager

© Vinay Avasthi
Table indexing
lEach conceptual row must include either an
INDEX or AUGMENTS clause
l Both the clauses are not allowed together
l SNMPv2 INDEX objects must be sufficient to
distinguish a conceptual row unambiguously
l Given an object with object identifier y in a
table with INDEX objects i1,i2,…,iN
l Instance identifier for an instance of object y in a
particular row is
l Y.(i1).(i2)…(iN)
© Vinay Avasthi
Instance identifier
lFor rows in a table, for each instance
identifier of type Y.(i1).(i2)…(iN), each
term in parentheses is interpreted as
follows
Type of instance identifier Description
Integer-valued A single sub-identifier takes the integer value
Each octet of the string is encoded as a separate sub-identifier, for a tota
fixed length
String-valued, variable string of n octets
length preceded by Each octet of the string is encoded as a separate sub-identifier, for a tota
IMPLIED keyword
String-valued, variable string of n octets
length not preceded by For a string of length n octets, the first sub-identifier is n followed by each
IMPLIED keyword
Object-identifier-valued separate sub-identifier for a total of n+1 sub-identifier
preceded by the IMPLIED For an object identifier with n sub-identifiers, the encoding is one value fo
keyword
Object-identifier-valued not order, for a total of n sub-identifiers
preceded by the IMPLIED For an object-identifier with n sub-identifiers, the first sub-identifier is n fo
keyword each sub-identifier in order, for a total of n+1 sub-identifier

© Vinay Avasthi
Augments clause
l Augments clause is used to increase the number of columns
in a table without re-writing the table definition
l It is useful in a situation where a core of information is to be
stored in a table and one of the several possible extensions to
the table depending on configuration.

© Vinay Avasthi
Table MAX-ACCESS
l Any object that is specified in the INDEX clause of a
conceptual row and is also a columnar object of that row is
termed an auxiliary object

l MAX-ACCESS clause of auxiliary object is not-accessible

© Vinay Avasthi
Table MAX-ACCESS

Operation In order to read any Reason forobject


columnar not being accessible
instance, it is neces
the value of the INDEX object(s) of the row instance; ther
to read the contents of an auxiliary variable is to know tho
Read already
If a manager updates the value of an auxiliary object inst
Write identity
The of the
create row is changed.
opearation, involvesThis is not permissible
assigning a value to a co
at the time of row instance creation; this is a task perform
Create agent and not the manager
© Vinay Avasthi
Row Creation and Deletion
l Two approaches were considered for this
l Define new PDUs Create and Delete
l Embed the semantics into MIB with a new textual convention
called RowStatus

l Second approach was adopted


l RowStatus can have following values
l Active, notInService, notReady, createAndGo,
createAndWait, destroy

© Vinay Avasthi
RowStatus semantics
lTwo methods were considered

Manager instructs agent to create a new row with a given instance


createAndWait

If all read-create objects have default values the row is put in notInS
If some read-create objects do not have default values, the row is p
notReady state
Manager uses get and set to set the values of all the columnar obje
Once all the columnar objects receive a valid value, manager sets t
status column to active
This method is limited to tables whose objects can fit in a single PD
teAndGo

Manager selects an instance identifier


© Vinay Avasthi
Manager issues a single set request for all the columnar objects
Tradeoff between createAndWait
andNocreateAndGo—
1
Type
checklistFeature
Must handle rows larger than one PDU
2 Must allow manager to learn of columns not implemented
3 Must allow manager to learn of columns not accessible
MANDATORY

4 Must arbitrate between multiple managers accessing same row


5 Must protect create operations from reordering
6 Must allow protocol entity to detect tooBig before create is exe
7 Must allow read-only and read-write to co-exist in same row
8 Should allow simplified agent
VIMP

9 Should keep protocol entity ignorant of row relationship


10 Should not add a new PDU type
11 Perform operations in one transaction
12 Should allow manager to accept default values
FUL

© Vinay Avasthi 13 Should allow manager to learn agent's default values and over
Evaluation between createAndWait
and createAndGo
No Category createAndWait createAndGo
1 Must Yes No
2 Must Yes Yes
3 Must Yes Yes
4 Must Yes Yes
5 Must Yes Yes
6 Must Yes Yes
7 Must Yes Yes
8 Important No Yes
9 Important Yes Yes
10 Important Yes Yes
11 Useful No No
12 Useful Yes No
13 Useful Yes No
© Vinay Avasthi 14 Useful Yes Yes
Table definition — Access category
Columnar Objects
Table that permits row creation Table that do
Object and deletion cr
INDEX object auxiliary not-accessible not-accessib
Status Object read-create —
read-create or read-only or read-write or
Other columnar objects accessible-for-notify accessible-fo
Noncolumnar objects related to the table
Table that permits row creation Table that do
Object and deletion cr
INDEX object auxiliary
© Vinay Avasthi
not-accessible not-accessib
SNMPv2 protocol operations
l Provides three types of access to management information
l Manager-agent request response
l Manager-manager request response
l Agent-manager unconfirmed

© Vinay Avasthi
Transmission of SNMPv2 message
l The PDU is constructed using ASN.1 structure

l PDU is passed through authentication service


l source and destination transport address and community is also
passed

© Vinay Avasthi
Transmission of SNMPv2 message
l Message is constructed consisting of a version field,
community name and results from previous step

l Object is encoded using basic encoding rules(BER) and


passed on to transport service

© Vinay Avasthi
Receipt of SNMPv2 message
l Basic syntax check is performed

l Version number is verified

l Protocol entity then passes the user name, PDU portion of


the message, and source and destination transport
addresses to authentication service

© Vinay Avasthi
Receipt of SNMPv2 message
l If authentication fails the message is discarded and a trap is
raised

l If authentication succeeds, the authentication service returns


a PDU in the form of a ASN.1 object

l PDU is processed based on the access policy defined with the


community name

© Vinay Avasthi
SNMPv2 formats
SNMP Message

Version Community SNMP PDU


Get Request PDU, GetNextRequestPDU, SetRequestPDU, SNMPv2-Trap-PDU, InformRequest-PDU
PDU type Request id 0 0 Variable bindings

ResponsePDU
PDU type Request id Error_status Error_index Variable bindings

GetBulkRequest-PDU
Non_repeater Max-
PDU type Request_id Variable bindings
s repetitions

Variable bindings
name1 value1 name2 value2 name3 …….. namen valuen
© Vinay Avasthi
SNMPv2 formats new terms
Variables Description
Definitions
non-repeaters field specifies the number of
variables in the variable bindingsN = MAX[MIN(non-repeaters, L),0]
list for
M =MAX[max-repetitions,0]
which a single lexicographic successor is to
non-repeaters be returned
L-N
max-repetitions field specifies theRnumber of
lexicographic successors to be returned for
the remaining variables in the variable
max-repetitions binding listDefinitions First N variables are processed as for GetNextRequest
number of variable names in the variable-bindings field of the
If R is greater than 0, than for each of the last R variables, its
L GetBulkRequest PDU
lexicographic
number of variables, starting with firest variable in variable bindings successors are retrieved
N field, for which a single lexicographic successor is requestedname1 name2 nameN nameN+1 nameN+ 2 nameN+ R
number of variables, following the first N variables, for which multiple
R lexicographic successors are requested First N variables provide First N variables provide one
number of lexicographic successors requested for each of the last R one value eac h, value eac h,
first lexicographic successor first lexicographic successor
M variables

© Vinay Avasthi
GetRequest & GetNextRequest
PDU
l Identical to SNMPv1 GetRequest & GetNextRequest except
the way in which responses are handled
l Contrary to SNMPv1, variable binding list is prepared and
returned even if values can not be supplied for all variables
l Each variable name in variable binding list is paired with an
indication of exception rather than a value in case of
exception

© Vinay Avasthi
GetRequest & GetNextRequest
PDU
l Error processing is performed for each of the variable name
in variable binding list in following manner
l If the variable does not have an OBJECT IDENTIFIER prefix that
exactly matches the prefix of any variable accessible by this
request then value field is set to noSuchObject

© Vinay Avasthi
GetRequest & GetNextRequest
PDU
l Error processing continued
l If the variable’s name does not exactly match the name of a
variable accessible by this request, then its value field is set
to noSuchInstance
l Otherwise, the value field is set to the value of named variable

© Vinay Avasthi
GetBulkRequest PDU
l One of major enhancements in SNMPv2
l Minimizes the number of protocol exchanges required to
retrieve a large amount of management information
l Uses same selection principle as of GetNextRequest
l Uses two fields non-repeaters and max-repetitions

© Vinay Avasthi
SetRequest PDU
l Similar to SNMPv1 SetRequest PDU except the way in which
responses are handled

l SNMPv2 SetRequest operation is also atomic like SNMPv1


operation

l More complicated validation and variable update is


performed

© Vinay Avasthi
SetRequest PDU — Validation
l Agent determines the size of response message
l If size exceeds local limitation or maximum size of request’s
source PDU is constructed with error-status of tooBig,
errorIndex or zero and empty variable binding list.

© Vinay Avasthi
SetRequest PDU — Validation
lIf not error then, following validations
are performed in order in the first
phase on each variable in variable
binding Condition Error code Condition
variable does not exist and
variable no accessible noAccess could never be created noCrea
object identifier does not exist notWritable variable can not be modified notWri
object type inconsistent with
desired type wrongType variable does not exist and
value length is inconsistent could not be created under
with required length wrongLength present circumstance incons
assignment requires a
ASN.1 encoding inconsistent wrongEncoding resource that is unavailable resour
illegal value wrongValue any other error genErr
© Vinay Avasthi
SetRequest PDU — variable update
l If no validation errors are encountered, an attempt is made
to update all of the variables in the SetRequest PDU

l For each variable in the list


l the named variable is created if necessary and the specified
value is assigned

© Vinay Avasthi
SetRequest PDU — variable update
l If any assignment fails, the all the assignments are undone
and a response PDU is issued with an error-status of
commitFailed
l If it is not possible to undo all of the assignments, then a
response PDU is issued with an error-status of undoFailed and
value of error-index set to zero

© Vinay Avasthi
SNMPv2-Trap PDU
l SNMPv2 trap differs than SNMPv1 trap in PDU format
l It uses same PDU format as GetRequest

l Variable binding field has following mandatory fields


l sysUpTime.0
l snmpTrapOID.0, part of the trap group in SNMPv2 MIB

© Vinay Avasthi
SNMPv2 -Trap PDU
lIf the OBJECTS clause is present in the
corresponding macro NOTIFICATION-TYPE
then each corresponding variable and its
value are copied to variable binding
lNo response is issued for SNMPv2-Trap PDU
lNOTIFICATION-TYPE macro is used to define
the information that is sent by an SNMPv2
entity when an exceptional event occurs
at the entity
© Vinay Avasthi
InformRequest PDU
l InformRequest PDU is sent by an SNMPv2 entity acting in a
manager role to another entity acting in manager role
l The PDU format is same as SNMPv2-Trap PDU

© Vinay Avasthi
InformRequest PDU
l InformRequest PDU is validated on the similar lines as
GetRequest

l If no error is generated then a ResponsePDU is generated


and and sent to the manager that originated the
InformRequest PDU

© Vinay Avasthi
Report PDU
l SNMPv2 specification includes a Report PDU, accompanied by
following comment
l Usage and precise semantics of Report-PDU are not presently
defined. Any SNMP administrative framework making use of
this PDU must define its usage and semantics

© Vinay Avasthi
Co-existence with SNMPv1, Proxy
agent behavior
l Proxy agent needs to perform two mappings
l SNMPv2 PDUs coming from and SNMPv2 manager are converted
to SNMPv1 PDUs
l GetRequest, GetNextRequest, and SetRequest PDUs are
passed unchanged
l GetBulkRequest PDU is converted to GetNextRequest PDU
with the same variable binding list
l The effect of this is that only the first row of max-
repetitions portion of the variable binding list is
returned

© Vinay Avasthi
Co-existence with SNMPv1, Proxy
agent behavior
l Proxy agent mappings continued…
l SNMPv1 PDUs coming from SNMP agent are converted to
SNMPv2 PDUs to be sent to SNMPv2 manager
l GetResponse is passed unchanged

l Trap PDU is converted into SNMPv2-Trap PDU by prepending


sysUpTime.0 and SNMPv2-TrapOID.0 to variable binding
list

© Vinay Avasthi
Co-existence with SNMPv1,
Bilingual Manager
l An alternative way to achieve co-existence is to employ
management stations that speak both SNMPv2 and
SNMPv1
l Management applications are written as if they were using
only SNMPv2
l For communication with SNMPv1 agents, the manager can
map operations to SNMPv1 operations

© Vinay Avasthi
SNMPv3
l RFC2 2271 through 2275, produced by SNMPv2 working
group, describe an overall architecture plus specific
message structures and security features
l These do not define new PDU formats
l SNMPv1 and SNMPv2 PDU formats must be used with new
architecture

© Vinay Avasthi
SNMPv3
l SNMPv3 specification consists of architecture and security
concepts defined in RFC 2271 through 2275 plus existing
SNMPv2 PDU format and functionality

l SNMPv3 can be defined as SNMPv2 plus security and


administration

© Vinay Avasthi
SNMPv3 design decisions
l Following key design decisions are made in SNMPv3
l Architecture
l Self-contained documents
l Remote configuration
l Controlled complexity
l Threats

© Vinay Avasthi
SNMPv3 design decisions —
architecture
l Architecture should define
l Conceptual boundaries
l Subsystems
l Abstract services provided
l Abstract service interfaces

© Vinay Avasthi
SNMPv3 design decisions — self-
contained documents
l Elements of procedure and related MIB objects should be
defined in the same document and should not be
referenced in other documents
l This helps in self-contained documents moving on standard
track on different time-lines

© Vinay Avasthi
SNMPv3 design decisions —
remote configuration
l Security and access control subsystems add a whole new set
of SNMP configuration parameters

l To make this deployable in large environments


l SNMP parameters must be able to be remotely configured

© Vinay Avasthi
SNMPv3 design decisions —
controlled complexity
l Design should have simple simple architecture and allow the
more complex environments to logically extend the simple
environments

© Vinay Avasthi
SNMPv3 design decisions —
threats
l Security model should protect against the principal threats
l Modification of information
l Masquerade
l Message stream modification
l Disclosure

l It need not protect against denial of service attack and traffic


analysis

© Vinay Avasthi
SNMPv3 design decisions —
threats
Modification of An entity could alter an in-transit message generated by an auth
information such a way to effect management operations, including setting
Management operations that are not authorized by some entity
Masquerade attempted by that entity by assuming identity of an authorized e
Message stream
modification SNMP messages could be re-ordered, delayed or replayed
An entity could observe exchanges between a manager and an
Disclosure thereby learn values of managed objects and learn of notifiable

© Vinay Avasthi
SNMP entities
Application(s)

Command Notification Proxy


generator receiver forwarder

Command Notification
Other
responder originator

SNMP Engine (identified by snmpEngineID)


Message Access
Security
Dispatcher processing control
subsystems
system subsystem

© Vinay Avasthi
SNMPv3 terminology
Terminology
Unique and unambiguous identifier of SNMP engine. It is defined by
snmpEngineId octet string
Identifies an SNMP entity that may realize an instance of a context wi
contextEngineId contextName
contextName Identifies a particular context within an SNMP engine
block of data consisting of a contextEngineID, a contextName and, an
scopedPDU passed to/from security system
Unique identifier for message processing model. Possible values are
snmpMessageProcessingModel SNMPv3. It is defined as textual convention as an integer
Unique identifier for security model of the security subsystem. Values
snmpSecurityModel SNMPv2c, USM. It is defined as textual convention as an integer
Level of security at which the message can be sent. Expressed in term
snmpSecurityLevel authentication and/or privacy is provided
© Vinay Avasthi The entity on whose behalf the services are provided. It can be an ind
particular role; a set of individuals, with each acting in a particular rol
Dispatcher
lAllows support for multiple versions of
SNMP
lResponsible for
l Accepting PDUs form applications
l Delivers PDUs to applications

l Passing PDUs to message processing subsystem

l Sending and receiving SNMP messages over


network
© Vinay Avasthi
Dispatcher — primitives
primitive
Used by a command generator to send an SNMP reques
sendPDU to another SNMP entity
Used by dispatcher to pass an incoming SNMP response
processResponsePDU application
Used by dispatcher to pass an incoming SNMP request o
processPDU an application
Used by a command responder to return a SNMP respon
returnResponsePDU response to an incoming request or notification PDU
Used to register responsibility for a specific contextEngin
registerContextEngineID pduTypes
Used to unregister responsibility for a specific contextEn
© Vinay Avasthi
unregisterContextEngineID pduTypes
Dispatcher — primitives

unregisterContextEngineID
registerContextEngineID
processResponsePdu
returnResponsePdu
processPdu
sendPdu
Parameter Descript
transportDomain IN Transport domain to be used
transportAddress IN Transport address to be used
messageProcessingModel IN IN IN IN Typically SNMP version
securityModel IN IN IN IN Security model to use/in use
securityName IN IN IN IN On behalf of this principal
securityLevel IN IN IN IN Level of security requested/in use
contextEngineID IN IN IN IN Data from/at this SNMP entity
contextName IN IN IN IN Data from/in this context
pduVersion IN IN IN IN Version of the PDU
PDU IN IN IN IN SNMP protocol data unit
expectResponse IN TRUE or FALSE
© Vinay Avasthi maxSizeResponseScopedPDU IN IN Maximumsize of response PDU
stateReference IN IN Reference or state information
Dispatcher — primitives —
sendPDU
l This primitive returns a primitive value of statusInformation
l If the operation was successful then statusInformation has value
of sendPduHandle
l This is a unique identifier that can be matched up later with
response pdu
l Application provides transport domain, address, message
processing model, security model, principal, level of security,
context and PDU

© Vinay Avasthi
Dispatcher — primitives —
processResponsePDU
l statusInformation parameter indicates success or failure of
the operation requested in matching preceding request or
notification PDU
l Matching request or notification PDU is identified by
sendPduHandle parameter
l Remaining input parameters are from incoming response
message

© Vinay Avasthi
Dispatcher — primitives —
processPDU
lstateReference parameter contains
security-related state information
generated by security sub-system
l Security subsystem may create state
information needed to generate a matching
response message, which is passed back to
security subsystem with outgoing response
message
l pduVersion parameter indicates version, other
© Vinay Avasthi parameters are from received message
Dispatcher — primitives —
returnResponsePDU
l Includes indication of maximum allowable size of PDU,
stateReference, statusInformation

l Remaining parameters as well as stateReference are from


processPdu call

© Vinay Avasthi
Message processing subsystem
lResponsible for
l preparing messages for sending
l Extracting data from received messages

lDefines three primitives, all of them represent


calls from dispatcher to message processing
system
l prepareOutgoingMessage
l prepareDataElements
l prepareResponseMessage

© Vinay Avasthi
Message processing system —
primitives
prepareResponseMessage

prepareResponseMessage
prepareOutgoingMessage

prepareOutgoingMessage
prepareDataElements

Parameter Description Parameter

transportDomain IN IN Origin transport domain maxSizeResponseScopedPDU IN OUT


transportAddress IN IN Origin transport address
messageProcessingModel IN IN OUT Typically SNMP version stateReference IN OUT
securityModel IN IN OUT Security model to use/in use statusInformation PV IN OUT
securityName IN IN OUT On behalf of this principal wholeMsg IN
Level of security requested/in
securityLevel IN IN OUT use wholeMsgLength IN
contextEngineID IN IN OUT Data from/at this SNMP entity destTransportDomain OUT OUT
contextName IN IN OUT Data from/in this context destTransportAddress OUT OUT
© Vinay Avasthi
pduVersion IN IN OUT Version of the PDU outgoingMessage OUT OUT
Message processing system —
primitives —
prepareOutgoingMessage
l It returns a primitive value of statusInformation, indicating
success or failure of message preparation

l Dispatcher provides a PDU as input parameter


l If message preparation is successful, receives a message
containing that PDU as an output parameter

© Vinay Avasthi
Message processing system —
primitives — prepareDataElements
l The dispatcher provides a message as input
l If message processing is successful, receives a PDU as output

l stateReference output parameter contains state information


to be used in a possible response

© Vinay Avasthi
Message processing system —
primitives —
prepareResponseMessage
l Used to request preparation of a message containing an
outgoing SNMP response PDU, in response to an incoming
request
l This primitive returns a primitive value of result, indicating
success or failure
l stateReference contains state information contained in the
corresponding prepareDataElements primitive

© Vinay Avasthi
Security subsystem
lProvides security services
l Authentication
l Privacy of messages
lCould potentially contain multiple security
models
lHas following primitives
l generateRequestMessage
l processIncomingMessage
l generateResponseMessage

© Vinay Avasthi
Security subsystem — primitives

generateResponseMsg
processIncomingMsg
generateRequestMsg
Parameter
messageProcessingModel IN IN IN Typically SNMP
globalData IN IN Message heade
maxMessageSize IN IN IN Of the sending S
securityModel IN IN IN For the outgoing
securityEngineID IN OUT IN Authoritative SN
securityName IN OUT IN On behalf of this
securityLevel IN IN IN Level of security
scopedPDU IN OUT IN Message payloa
Filled in by secu
securityParameters OUT IN OUT message
Complete gener
wholeMsg OUT IN OUT received on wire
© Vinay Avasthi
wholeMsgLength OUT IN OUT Length of gener
Security subsystem — primitives —
generateRequestMessage
lMessage processing system provides a
message header,
scopedPDU(contextEngineID,
contextName, PDU) as input parameter
and receives a prepared message
l Prepared message has authentication and
encryption applied
lIt returns a primitive value of
statusInformation indicating success or
failure of message generation
l Associated
© Vinay Avasthi
security parameters are also
Security subsystem — primitives —
processIncomingMessage
lProvides security processing for incoming
message and returns primitive
statusInformation indicating success or failure
of security processing
lMessage processing system provides message
received from network as input
lMessage processing system receives PDU as
output with an indication of pduType
l securityStateReference contains state information
for a possible response
© Vinay Avasthi
Security subsystem — primitives —
generateResponseMessage
lUsed to generate a message containing an
outgoing response in response to an
incoming request
lMessage processing system provides a
message header and a scopedPDU as
input to this system
lMessage processing system receives a
prepared message with authentication and
© Vinay Avasthi
Access control subsystem
l Provides a set of authorization services
l Application uses these services to check access rights

l Provides a single primitive to define the interface between


SNMP application and access control subsystem

© Vinay Avasthi
Access control subsystem —
primitives
Parameter isAccessAllowed Descr
securityModel IN Security model in use
securityName IN Principal who wants access
securityLevel IN Level of security
viewType IN read, write, or notify view
contextName IN Context containing variableN
variableName IN OID for managed object
statusInformation PV Success or error indication

© Vinay Avasthi
SNMPv3 applications
l RFC2273 defines procedures followed by each type of
application

l Procedures are defined in terms of interaction with the


Dispatcher by means of Dispatcher primitives

© Vinay Avasthi
Command generator
l Initiates Get, GetNext, GetBulk, and/or Set request PDUs

l Processes the response to a request that it has generated

l Command generator application makes use of sendPdu and


processResponsePdu

© Vinay Avasthi
Command generator — sendPdu
l sendPdu provides the dispatcher with information about the
intended destination, security parameters, and the actual
PDU to be sent
l Dispatcher then invokes message processing model for further
processing

l This interaction returns sendPduHandle that command


generator can store to match subsequent responses to the
original request

© Vinay Avasthi
Command generator —
processResponsePdu
lDispatcher delivers each incoming response
to correct command generator using
processResponsePdu primitive
lCommand generator examines received
values of messageProcessingModel,
securityModel, securityName,
contextEngineID, contexctName, and
pduVersion to those in the corresponding
request PDU using sendPduHandle to
identify request
© Vinay Avasthi
Command generator —
processResponsePdu
l Command generator examines contents of response PDU
l Extracts the operation type, request-id, error-status, error-index,
and variable binding

l If previous steps succeed then an implementation dependent


action is taken

© Vinay Avasthi
Command responder
l Receives SNMP Get, GetNext, GetBulk, and/or Set request
PDUs destined to local system
l Command responder function will perform the appropriate
protocol operation, using access control, and will generate a
response message to be sent to the request’s originator

© Vinay Avasthi
Command responder —
registerContextEngineID
l This primitive enables a command responder application to
associate itself with SNMP engine for the purpose of
processing certain PDU types for a context engine
l Once the registration is successful, all asynchronously received
messages containing the registered combination of
contextEngineID and pduType supported are sent to the
command responder

© Vinay Avasthi
Command responder —
unregisterContextEngineID
l This primitive is reverse of registerContextEngineID primitive

lA command responder can disassociate itself from an SNMP


engine using the unregisterContextEngineID primitive

© Vinay Avasthi
Command responder —
processPdu
lDispatcher delivers each incoming request PDU
to correct command responder application
using processPdu primitive
l Command responder verifies operation type to be a
valid type
l Command responder determines if the access is
allowed
l If access is permitted command responder performs
the operation and prepares a response PDU
l If access is failed command responder prepares a
response PDU indicating failure
l Command responder calls dispatcher with a
returnResponsePdu primitive to send the response
© Vinay Avasthi
PDU
Notification originator
lMonitors a system for particular events or
conditions, and generates Trap and/or Inform
messages based on these events or
conditions
lA notification originator must have a mechanism for
determining
l where to send messages
l which SNMP version to use
l security parameters to use

lUses same procedure as command generator


application
© Vinay Avasthi
Notification receiver
l Listens for notification messages

l Generates response messages when a message containing


Inform PDU is received

l Uses same procedure as command responder application

© Vinay Avasthi
Proxy forwarder
l Forwards SNMP messages

l Makes use of dispatcher primitives to forward SNMP


messages

l This is optional

© Vinay Avasthi
Proxy forwarder
l Following types of messages are handled
l Messages containing PDU types from a command generator
application
l Messages containing PDU types from a notification originator
application
l Messages containing a response PDU type
l Messages containing a report indication

© Vinay Avasthi
SNMP entity intra module
interfaces
l Services between modules in an SNMP entity are defined in
terms of primitives and parameters

l Primitive specifies the function to be performed

l Parameters are used to pass data and control information

© Vinay Avasthi
Abstract service interface
l An interface defined using primitives and parameters is
called abstract service interface

© Vinay Avasthi
Message processing msgVersion
msgID
msgMaxSize
lIn SNMPv3 msgFlags
msgSecurityModel
information is msgSecurityModel
contextEngineID
exchanged contextName
between SNMP
entities in the
form of
messages PDU

lEach message
includes a header
and a PDU
© Vinay Avasthi
SNMPv3 message format
SNMPv3 message format
msgVersion snmpv3(3)
msgID unique identifier used to coordinate requests and response messages. R
maximum size of a message in octets supported by the sender of the me
31
msgMaxSize 2 -1
An octet string containing three flags in the least significant three bits: re
msgFlags privFlag, authFlag
31
An identifier in the range 0 through 2 -1 that indicates the security mode
msgSecurityModel values are 1 for SNMPv1, 2 for SNMPv2c, and 3 for USM
An octet string that contains parameters generated by the security subsy
SNMP entity and procesed by the security subsystem in the receiving en
msgSecurityParameters are not interpreted by message processing system or dispatcher
© contextEngineID
Vinay Avasthi An octet string that uniquely identifies an SNMP entity
SNMPv3 message format —
msgFlags

reportableFlag is set to 1 by the sender in all messages corresponding to Get, Set, G


reportableFlag set in Trap and Report. Secondary usage is to determine when to send a Report PD
privFlag is set to 1 by sender to indicate the
privFlag security level that was applied
authFlag is set to 1 by sender to indicate All combination are allowed except priv
authFlag authentication that was applied i.e. encryption without authentication is

© Vinay Avasthi
SNMP engines
l When any SNMP message contains a payload which expects
a response(Get, GetNext, Set, Inform, GetBulk), then the
receiver of such message is authoritative

l When an SNMP message contains a payload that does not


expect a response (SNMPv2-Trap, Response, Report), then
the sender of such a message is authoritative

© Vinay Avasthi
SNMP engine types — purpose
l The timeliness of a message is determined with respect to a
clock maintained by the authoritative engine
l Every time non-authoritative engine receives a message, it can
synchronize its clock
l Authoritative engine can assess the timeliness of a message
from the time-stamp received in the message

© Vinay Avasthi
SNMPv2 USM
l USM stands for user based security model
l Defined in RFC2274
l It encompasses
l Authentication — Data integrity and authentication
l Timeliness — Protects against delay
l Privacy — Encryption
l Message format — defines format of
msgSecurityParameters field
l Discovery — defines procedures by which one SNMP
engine obtains information about other
l Key management — defines procedure for key
© Vinay Avasthi
generation, update and use
USM security parameters
Parameter & Description
snmpEngineID of the authoritative SNMP engine involved in the
msgAuthoritativeEngineID message
snmpEngineBoots value of authoritative SNMP engine involved
message. It represents number of times this engine has initializ
msgAuthoritativeEngineBoots since its initial configuration
snmpEngineTime value of authoritative SNMP engine involved in
message. It represents the number of seconds since this engin
msgAuthoritativeEngineTime snmpEngineBoots object
msgUserName The user on whose behalf the message is being exchanged
Null if authentication is not being used. For current definition, th
msgAuthenticationParameters parameter is an HMAC message authentication code
Null if privacy is not being used, For current definition, the priva
msgPrivacyParameters
© Vinay Avasthi value used to form initial value in the DES CBC algorithm
USM timeliness mechanism
l USM timeliness mechanisms include the following
l Management of authoritative clocks
l Synchronization
l Timeliness checking

© Vinay Avasthi
Management of authoritative
clocks
l Each SNMP engine wishing to act as an authoritative engine
maintains two objects
l snmpEngineBoots
l snmpEngineTime

l These values are initialized to 0 on installation

© Vinay Avasthi
Management of authoritative
clocks
lIn case of inability to determine
snmpEngineBoots value, this value is set
to its maximum value
l Once the value reaches the maximum value it
remains latched to that value
l Any authenticated message always causes
notInTimeWindow authentication failure
l Once the engine reaches this state it is required
to manually re-configure the system with a
© Vinay Avasthi
new value
Management of authoritative
clocks
l All agents and all managers that can receive Inform
messages must maintain these two objects

© Vinay Avasthi
Synchronization
l SNMP engines must remain loosely synchronized with each
authoritative SNMP engine with which it communicates

© Vinay Avasthi
Synchronization
l Non-authoritative engine keeps local copies of following
values
l snmpEngineBoots
l snmpEngineTime
l latestReceivedEngineTime

© Vinay Avasthi
Synchronization —
lastReceivedEngineTime
llatestReceivedEngineTime is the highest
value of msgAuthoritativeEngineTime that
has been received by this engine from
remote authoritative engine.
l This value is updated whenever a larger value is
received
l This value is used to protect against a replay
message attack that would prevent non-
authoritative SNMP engine’s notion of
© Vinay Avasthi snmpEngineTime from advancing
Synchronization
lOne set of there values are stored on per
authoritative engine basis
lAuthoritative engines insert their current
boot and time values, snmpEngineID in
each outgoing Response, Report or Trap
message in following fields
l msgAuthoritativeEngineBoots
l msgAuthoritativeEngineTime
l msgAuthoritativeEngineID
© Vinay Avasthi
Synchronization
lOn receive of a message, receiving non-
authoritative engine updates
snmpEngineBoots, snmpEngineTime,
snmpEngineID
lAn update will occur on one of two
conditions
l (msgAuthoritativeEngineBoots >
snmpEngineBoots) OR
l [(msgAuthoritativeEngineBoots =
© Vinay Avasthi
Synchronization
lIf update is called for, then following
changes are made
l snmpEngineBoots =
msgAuthoritativeEngineBoots &
snmpEngineTime =
msgAuthoritativeEngineTime &
latestReceivedEngineTime =
msgAuthoritativeEngineTime
lSynchronization is applied only if
© Vinay Avasthi
authentication service is in use
Timeliness checking Non-authorita
Authoritative Receiver Rece
IF((MAEB>SEB) OR
[(MAEB=SEB) AND
(MAET>LRET)] THEN
[SEB = MAEB;SET =
Clock Synchronication Not applicable
Inside time window MAET; LRET = MAET
31
IF(SEB != 2 -1) AND Inside time window
31
(MAEB=SEB) AND IF(SEB != 2 -1) AND
(SET- (MAEB>SEB) OR
150<=MAET<=SET+150 [(MAEB=SEB) AND
Timeliness Check
© Vinay Avasthi
) (SET-150<=MAET)]
Discovery
l Non-authoritative engine send a Request message to
authoritative engine with a requested securityLevel of
noAuthnoPriv

l Message includes
l msgUserName = initial
l msgAuthoritativeEngineID = Null
l Varbind = Empty

© Vinay Avasthi
Discovery
l Authoritative engine responds with a Report message
containing snmpEngineID in msgAuthoritativeEngineID field

l If authenticated communication is required then


l Non-authoritative engine establishes time-synchronization with
authoritative engine
l It sends a authenticated Request message

© Vinay Avasthi
Discovery
l Request message is populated with
l msgAuthoritativeEngineID = snmpEngineID
l msgAuthoritativeEngineBoots = 0
l msgAuthoritativeEngineTime = 0

l Response message will be a report message with correct


values of snmpEngineBoots and snmpEngineTime

© Vinay Avasthi
Key Management
lA secret authentication key and a secret
privacy key must be exchanged between a
non-authoritative engine and a
authoritative engine
lThese keys are not stored in MIB and are
not accessible using SNMP
lEach principal is required to maintained a
single authentication key and a single
encryption key
© Vinay Avasthi
Key management
l User requires a 16-octet privacy key and an authentication
key either 16 or 20 octets in length

l User provides a human-readable password

© Vinay Avasthi
Key management — key
generation
lRFC2274 provides algorithm for mapping
password to key
l Take user’s password and produce a string of
length 220 octets by repeating password value
as many time as necessary, truncating the last
value if necessary
l If a 16-octet key is required, take the MD5 hash
of the string
l If a 20-octet key is required, take the SHA-1
© Vinay Avasthi hash of the string
Key management — key
localization
l Every SNMP agent has its own unique key for every user.
Thus is a user is compromised, keys for other users are still
valid

l Every user has different keys for agents, thus if a agent is


compromised, keys for other agents are still valid

© Vinay Avasthi
Key management — key
localization
l User may have to remember a large number of keys, one per
managed element

l An adversary who learns a key for one agent is now able to


impersonate any other agent to any user, or any user to
any other agent

© Vinay Avasthi
Key management — key
localization
lTO address these problems, a single user key
is mapped by means of a non-reversible one-
way function into different localized keys
lThe procedure is very similar to key creation
procedure
l Take user’s key and produce a string of length 220
octets by repeating password value as many time
as necessary, truncating the last value if necessary
l If a 16-octet key is required, take the MD5 hash of the
string
l If a 20-octet key is required, take the SHA-1 hash of the
string
lThe
© Vinay Avasthi output is localized key
Key management — key update
lRequester performs following steps
l Generatea pseudo-random or true random number
“random”
l Computer digest = Hash(keyOld||random)
l || is concatenation
l Hash is either MD5 or SHA-1
l Compute delta = digest XOR keyNew
l protocolKeyChange = (random||delta)

lprotocolKeyChange is then sent to agent in set


command to update a key change object
© Vinay Avasthi
Key management — key update
l Receiver performs following steps
l digest = Hash(keyOld||random)
l keyNew = digest XOR delta

© Vinay Avasthi
Key management — key update
lRequestor
l computes a digest value from old key and a
random number and sends the random
number to receiver
l sends XOR or keyNew and digest as delta

lReceiver
l computes same digest by using same random
number
l performs XOR on digest and delta and gets
© Vinay Avasthi
View based access control
l It is desirable to restrict access of a particular group to a sub-
set of managed objects at the agent

l Abstract service interface is used to enforce this

© Vinay Avasthi
View based access control
lView based access control helps in
enforcing a access control policy based on
l Different access privileges for different users
l Security level by which request was
communicated
l Security model used for processing the request
l MIB context
l Object instance
l Type of access requested

© Vinay Avasthi
VACM — Access control logic
l VACM performs following steps
l Checks to see if there is an entry in vacmContextTable for this
contextName
l If not, then an errorIndication of noSuchContext is returned
l Checks vacmSecurityToGroupTable to determine if there is a
group assigned to this <securityModel, securityName> pair
l If not, then an errorIndication of noGroupName is returned

© Vinay Avasthi
VACM — Access control logic
l Consults vacmAccessTable with groupName, contextName,
securityModel, and securityLevel as indices
l If an entry is found then an access control policy is defined
l If not, then an errorIndication of noAccessEntry is returned

© Vinay Avasthi
VACM — Access control logic
l Determine if select vacmAccessTable entry includes
references to MIB view of viewType.
l If yes then this entry contains a viewName for this combination
of groupName, contextName, securityModel, securityLevel,
and viewType
l If not, then an errorIndication of noSuchView is returned

© Vinay Avasthi
VACM — Access control logic
l viewName is used as an index into vacmViewTreeFamilyTable.
l If a view is found then a view is configured for this viewName
l If not found, then an errorIndication of noSuchView is returned

© Vinay Avasthi
VACM — Access control logic
l Check the variable name against the MIB view
l If the variable is included in the view then statusInformation of
accessAllowed is returned
l If not, then errorIndication of notInView is returned

© Vinay Avasthi
The end for now

© Vinay Avasthi

You might also like