Scribd
Upload
40 views

L33 SNMPv3

SNMPv3 improves on SNMPv2 by adding security features and an administration framework. It defines the overall architecture consisting of SNMP entities with a dispatcher, message processing, security, and access control modules. SNMP entities can be managers with command and notification applications or agents with command response, notification, and proxy applications. SNMPv3 introduces authentication and encryption to address security issues.

Uploaded by

Shivam Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
40 views

L33 SNMPv3

SNMPv3 improves on SNMPv2 by adding security features and an administration framework. It defines the overall architecture consisting of SNMP entities with a dispatcher, message processing, security, and access control modules. SNMP entities can be managers with command and notification applications or agents with command response, notification, and proxy applications. SNMPv3 introduces authentication and encryption to address security issues.

Uploaded by

Shivam Kushwaha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

SNMP v3

What’s New in SNMPv3 ?


 SNMPv3 = SNMPv2 +Security +
Administration
 Address security issues of SNMP:
RFC 2271-2275,2570,2575,2586,3411-3418
 Defines overall architecture and several
textual conventions
 To be used together with SNMP v1 & v2
 Both managers and agents are called SNMP
entities.
SNMPv3 Architecture
 As envisioned by RFC 2271, the
architecture consists of a distributed,
interacting collection of entities.

 Each SNMP entity consists of a collection


of modules that interact with each other to
provide services.

 Thisinteractions can be modeled as a set


of abstract primitives and parameters. The
services between modules are defined in
terms of primitives and parameters.
SNMPv3 Entities (1/2)
 An SNMP entity consists of applications
and a single SNMP engine (identified by
snmpEngineID).
 The SNMP engine is composed of:
 Dispatcher – sends and receives messages
 Message processing – prepares messages to be
sent and extracts the data from the received
messages
 Security – provides authentication and privacy
services
 Access control – is responsible for controlling
access to MIB objects, to control what objects a
user can access and what operations she is
allowed to perform on those objects
SNMPv3 Entities (2/2)
 Both the SNMP engine and the
applications are defined as a collection of
discrete modules to enable alternative or
enhanced capabilities to be defined.

 Each ENMP entity manage a number of


contexts of managed information, each of
which has a contextName that is unique
with that entity.

 User based authentication uses MD5 or


SHA algorithms to authenticate users
without sending a password in the clear.
The privacy service uses DES to encrypt
SNMPv3 Applications
 Command generator (Get, GetNext, GetBulk, Set)
 Command responder
 Notification originator (InformRequest)
 Notification receiver (InformRequest, SNMPv2-Trap)
 Proxy forwarder

 An agent contains: proxy forwarder, command


responder, and notification originator
A manager contains: command generator,
notification originator, and notification receiver
Traditional SNMP Manager
 The SNMP engine performs 2 overall functions”
 It accepts outgoing PDUs from SNMP applications,
processes and encapsulates PDUs into messages.
 It accepts incoming SNMP messages from the
transport layer, processes and extracts PDUs and
passes on to the appropriate SNMP application.
 For traditional manager, the SNMP engine
contains the followings to service command
generator, notification originator, and notification
receiver applications:
 Dispatcher
 Message processing subsystem (v1,v2c, v3)
 Security subsystem (USM)
Traditional SNMP Agent
 For agent, the SNMP engine contains the
followings to service command responder,
notification originator, and proxy forward
applications:
 Dispatcher
 Message processing subsystem (v1,v2c, v3)
 Security subsystem (USM)
 Access control subsystem (VACM)

 Note that security-related functions are organized


into two separate subsystems: security (privacy,
USM) and access control (authentication, VACM)
Traditional Manager Applications
A manager contains applications of command
generator, notification originator, and notification receiver
1. Command generator – monitors and manipulates
management data at remote agents using Get,
GetNext, GetBulk and Set.
2. Notification Originator Application - initiates
asynchronous messages using InformRequest
PDU.
3. Notification Receiver Application - processes
incoming asynchronous messages using
InformRequest, SNMPv2-Trap, and SNMPv1
Trap PDU. In case of InformRequest PDU, the
Notification Receiver Application will respond with
a Response PDU.
Traditional Agent Applications
 An agent contains applications of proxy forwarder,
command responder, and notification originator.
1. Command responder applications provide access
to management data. These applications respond
to incoming requests by retrieving and/or setting
managed objects and then issuing a Response
PDU.
2. Notification originator initiates asynchronous
messages using SNMPv2-Trap or SNMPv1 Trap
PDU.
3. Proxy forwarder forwards messages between
entities.
Message Processing Subsystem Primitives
 Define the interface between Dispatcher and Message
Processing Subsystem.
 Primitives include
 sendPdu (command generator or notification originator)
 processResponse Pdu
 ProcessPdu (command responder)
 returnResponsePdu
 registerContextEngineID
 unregisterContextEngineID
 Parameters include
 TransportDomain
 securityModel
 PDU
 pduType, etc
Access Control Subsystem Primitives
 Define the interface between SNMP applications and the
Access Control Sybsystem.
 Primitives include
 sendPdu (command generator or notification originator)
 processResponse Pdu
 ProcessPdu (command responder)
 returnResponsePdu
 registerContextEngineID
 unregisterContextEngineID
 Parameters include
 TransportDomain
 securityModel
 PDU
 pduType, etc
Access Control Processing
 statusInformation = isAccessAllowed
(securityModel, securityName, securityLevel, viewType,
contextName, OID variable)
 returned value could be: accessAllowed,
notInView, noSuchView, noSuchContext,
noGroupName, noAccessEntry
 Input to the Access Control Decision:
 Who – who wants access
 Where – contextName
 How – securityModel and securityLevel
 Why – viewType (r/w/n)
 What -- objectType
 Which – objectInstance
Access Control Logic and VACM MIB
 VACM MIB contains following information:
 Local contexts
 Groups

 Access rights

 MIB views

All are defined in vacmMIBObjects

You might also like