1. Agenda
1. QUIZ
2. SNMP
3. SNMPv2
4. SNMPv3

2. SNMP Management-Two Tier
MIB
Manager
Manager
Anything that pulses
the managed object gets
a response
Managed
Object
agent
Managed Objects

3. SNMP Management-Three Tier
MIB
Manager
Manager
Remote Monitoring
(RMON) can add
preprocessed data from
a probe extension
Managed
Object
agent
Managed Objects
RMON Probe

4. SNMP Management-Proxy Server
MIB
Manager
Manager
Proxy Server
Managed
Object
Wireless LAN
agent
Server monitors objects
without agents by
converting data into
compatible formats
Managed Objects
RMON Probe

5. SNMP Background Management Information Base (MIB) tree:
1. Defined by ISO Abstract Syntax Notation One (ISO ASN.1).
2. Each piece of info in the ASN.1 tree is a labeled node.
a. Each labeled node contains an object identifier (a series
of integers and periods) and a short text description.
b. Labeled nodes have subtrees or leaf nodes or they have
a value known as an object.
Root
Directory
ccitt(0) iso(1) joint-iso-ccitt(2)
Object Identifier 1.3
org(3)

6. ASN.1 Syntax (for MIB ) 1.3.6.1.2.11= ? iso(1) org(3) dod(6)
Internet(1)
experimental(3) private(4)
directory(1)
management(2)
system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6)
mib(1)
system(1) interfaces(2) address translation(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) cmot(9) tsmsn(10) snmp(11)
mib(2)

7. SNMP SNMP MESSAGE TYPES Type Purpose
Get-Request To retrieve information from a network
device that has an SNMP agent
Get-Response Provide a response from the SNMP agent to
an SNMP station
Get-Next-Request To retrieve the next specific object from a
table in lexigraphical order
Set-Request To remotely configure parameters on a
device

8. SNMP SNMP TRAP TYPES Type Indication
Coldstart of a system Agent is reinitializing itself since its
configuration has changed
Warmstart of a system Agent is reinitializing itself but its
configuration has not changed
Link down Link failure
Link up Link restoral
Failure of Authentication Request does not have proper authentication
e.g., wrong SNMP community string
EGP neighbor loss Exterior Gateway protocol neighbor gone
Enterprise specific Specific to vendor implementing it

9. SNMP Network Management Architecture
SNMP MGR
SNMP Agent
MDB
SNMP Manager
Application
SNMP Manager
Application
get-next-request
get-next-request
get-request
set-request
get-request
set-request
get-response
trap
get-response
trap
SNMP
UDP IP
Data Link
Physical
SNMP
UDP IP
Data Link
Physical

10. SNMPv2
SNMP DRAWBACKS
1. Officially standardized only for use on IP networks
2. Inefficient for large table retrievals
3. Uses cleartext strings for security, leaving it relatively unsecure
4. Standards are always necessary but never sufficient
SNMPv2 FEATURES INCLUDE:
1. Additions to the SMI
2. New Message types
3. Standardized multiprotocol support
4. Enhanced security
5. New MIB objects
6. Backward compatibility

11. SNMPv2 Request For Comment (RFC) Standards RFC Description
1442 Updated SMI
1443 New textual conventions
1445 Administrative model
1446 Security protocols
1447 Party MIB
1448 Protocol operations
1450 SNMPv2 MIB
1592 SNMP Distributed Protocol Interface

12. SNMPv2 SNMP MESSAGE TYPES Type Purpose
Get-Request To retrieve information from a network
device that has an SNMP agent
Get-Response Provide a response from the SNMP agent to
an SNMP station
Get-Next-Request To retrieve the next specific object from a
table in lexigraphical order
Set-Request To remotely configure parameters on a
device
InformRequest Provide mgr-to-mgr communications
GetBulkRequest Request multiple retrievals of an object
(Get-Next-Request asking for multiple #s)

13. SNMPv2 MIBs SNMP uses three management information bases SNMPv2 MIB
Manager-to-manager MIB
Party MIB

14. SNMPv2 MIBs SNMPv2 MIB GROUPS Name Provides Objects To:
SNMPv2 Statistics Group Give stats about manager or agent, mostly
msgs that could not be processed
SNMPv1 Statistics Group Give stats about manager or agent that
communicates with SNMPv1
Purpose
Object Resource Group Provide information that defines which
objects an agent can define dynamically
Traps Group Provides information about each of the
traps an agent can send
Set Group Provides a single object that allows
multiple managers to send SNMP Set
messages to a single agent (set serial #)

15. SNMPv2 MIBs MANAGER-TO-MANAGER MIB GROUPS Name PURPOSE
The Alarm Group The objects in this group allow you to
define two thresholds over a
duration of time
The Event Group The objects in this group allow you to
define events. It has two tables,
one to specify the type of
notification the probe should invoke
when the event triggers and the
second to log the event.

16. SNMPv2 MIBs PARTY MIB Name PURPOSE
The Party Database Group Information which is stored on the
device about all known local and
remote parties.
The Contexts Database Group
Deal with privileges
The Access Privileges Database Group between manager
and agent, e.g., local
MIB View Database Group and remote contexts,
access control policies,
defined MIB views, etc.

17. SNMPv3 Architecture
The third version of the Simple Network Management Protocol (SNMPv3) was
Published as proposed standard in RFCs 2271 to 2275 in January This version is build upon the two first versions of SNMP and so it reuses the SNMPv2 standards documents (RFC 1902 to RFC 1908).
The architecture of SNMPv3 is more complex than that of previous versions. This is because of added security and enhanced functionality.
Some of the most recent SNMPv3 documents are:
RFC 2571 An Architecture for Describing SNMP Management Frameworks
RFC 2572 Message Processing and Dispatching for SNMP
RFC 2573 SNMPv3 Applications
RFC 2574 User-Based Security Model for SNMPv3
RFC 2575 View-Based Access Control Model (VCAM) for SNMP
Internet Draft Introduction to Version 3 of the Internet Network Management Framework
Note: All released in December 2002

18. SNMPv3 Design Goals
The following design goals guided the development of SNMP architecture.
Use existing material as much as possible.
Address the need for SET REQUEST message support
Move portions of the architecture forward in the standards track.
Design an architecture that allows implementation over a wide range of operational environments.
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.
Accommodate alternate security models in large networks.

19. Design Decisions Made
Based on the goals, a number of decisions were made.
Architecture:
Identify the conceptual boundaries between the documents.
Describe the abstract services provided by specific portions of an SNMP framework.
Abstract service interfaces, define the abstract boundaries between documents and abstract services provided by an SNMP framework.
Self-contained documents:
Elements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document and, as much as possible, should not be referenced in other documents.
As portions of SNMP change over time, the documents describing other portions of SNMP should not change.

20. Design Decisions Made (cont.)
Remote Configuration:
Frequent changes of secrets at various SNMP entities should be deployable in large operational environments.
These SNMP parameters must be able to be remotely configured.
Controlled complexity:
Keep the resources used by SNMP devices to a minimum.
Use resources for more complex configurations which provide more functionality
Threats:
The security model in the security subsystem should protect against the principal threats.

21. Principal threats
SNMPv3 is designed to secure against the following principal threats:
Modification of Information:
An entity could alter an in-transit message generated by an authorized entity in such a way as to affect unauthorized management operations, including the settings of object values.
Masquerade:
Management operations that are not authorized for some entity may be attempted by that entity by assuming the identity of an authorized entity.

22. Principal threats (cont.)
Message Stream Modification:
SNMP messages could be reordered, delayed, or replayed (duplicated) to
effect unauthorized management operations.
Disclosure:
Eavesdropping on the exchanges between two SNMP entities.
SNMP is NOT intended to secure against the following two threats:
Denial of Service:
An attacker/hacker may prevent exchanges between manager and agent.
Traffic Analysis:
An attacker/hacker may observe the general pattern of traffic between managers and agents.

23. SNMP Entities (architecture)
The SNMP architecture consists of distributed, interacting collection of SNMP entities.
Each entity implements a portion of the SNMP capability and may act as an agent node, a manager node, or a combination of the two.
Each SNMP entity consists of a collection of modules that interact with each other to provide services.
Each SNMP entity includes a single SNMP engine.
The engine implements functions for sending and receiving messages, authenticating and encrypting/decrypting messages, and controlling access to managed objects.
The role of an SNMP entity is determined by which modules are implemented in that entity.

24. SNMP entity (RFC 2271) SNMP Engine (identified by SNMPEngineID)
Application(s)
Command
Generator
Notification
Receiver
Proxy
Forwarder
Command
Responder
Notification
Originator
Other
SNMP Engine (identified by SNMPEngineID)
Dispatcher
Message
Processing
subsystem
Security
subsystem
Access
control
subsystem

25. SNMP (architecture) Dispatcher subsystem:
One dispatcher in an SNMP engine
transport mapper delivers messages over the transport protocol.
Handles multiple version messages
- Determines version of a message and interacts with corresponding module
Interfaces with application modules, network, and message processing models
Three components for three functions
Transport mapper delivers messages over the transport protocol
Message Dispatcher routes messages between network and appropriate module of MPS
PDU dispatcher handles messages between application and MSP

26. SNMP (architecture cont.)
Message Processing Subsystem:
Contains one or more Message Processing Models
Interacts with dispatcher to handle version-specific SNMP messages
One MPS for each SNMP version
SNMP version identified in the header
Security and Access Control Subsystem:
Security at the message level
Authentication
Privacy of message via secure communication
Flexible access control
Who can access
What can be accessed
Flexible MIB views

27. SNMP Manager
A software application that runs on a UNIX, PC or Macintosh computer.
In SNMPv3, SNMP manager includes three categories:
The Command Generator Applications:
It monitors and manipulates management data at remote agents.
Notification Originator application:
It initiates asynchronous messages
Notification Receiver Application:
It processes incoming asynchronous messages and responds to them with a Response PDU
All these applications use the services provided by the SNMP engine.

28. SNMP Manager

29. SNMP Engine The SNMP engine performs two major functions:
It accepts outgoing PDUs from SNMP applications, performs
the necessary processing, including inserting authentication
codes and encrypting, and then encapsulates the PDUs into messages for transmission.
It accepts incoming SNMP messages from the transport layer, performs the necessary Processing, including authentication
and decryption, and than extracts the PDUs from the messages and passes these on to the appropriate SNMP application.

30. SNMP Agent
Agents are any devices on the network that need to be managed and that
have the SNMP protocol and the Management Information Base.
Agents monitor the desired objects in their environment.
Package this information from objects in the appropriate manner.
Send it to the management station either immediately or upon request.
Information is generated by the Agent, stored in its MIB, and made available
to the Manager.
The SNMP agent contains three types of applications:
Command Responder Application provides access to management data.
Notification Originator Application initiates asynchronous messages.
Proxy Forwarder Application forwards messages between entities.

31. SNMP Agent

32. SNMPv3 Message Formats SNMPv3 Message Msg Version Header Data Msg
Security Parameters
Scoped
PDU Data
Msg ID
Msg
Max Size
Msg
Flags
Msg
Security Model
Context
Engine ID
Context
Name
Data
scopedPDU
(plaintext) or
Encrypted PDU
Encrypted scopedPDU (cyphertext)

33. SNMP Applications: Application Example Command generator get-request
Notification
Receiver
Proxy
Forwarder
Command
Responder
Notification
Originator
Other
Application Example
Command generator get-request
Command responder get-response
Notification originator trap generation
Notification receiver trap processing
Proxy Forwarder get-bulk to get-next (SNMP versions only)
Other Special application

34. SNMP Applications: (cont.)
There are no restrictions on which types of applications may be associated
with a particular SNMP engine. A single SNMP engine may, in fact, be
associated with both command generator and command responder
applications.
Command Generator Applications:
These applications monitor and manipulate management data.
Command generator application initiates SNMP Get, GetNext, GetBulk,
and/or Set requests, as well as processing the response to a request which it generated.
The Dispatcher is responsible for delivering the response to a particular request to the correct command generator application.

35. Command Generator Network Message Processing Security Command Model
Dispatcher
sendPDU
prepareOutgoing
Messages
generateRequestMsg
sendPDU
Handle
Send get-request msg
Network
Receive get-response msg
prepareDataElements
processIncomingMsg
processResponse
PDU

36. SNMP Applications: (cont.)
Command Responder Applications:
These applications provide access to management data.
Command responder application receives SNMP Get, GetNext, GetBulk,
and/or Set requests destined for the local system as indicated by the fact
that the contextEngineID in the received request is equal to that of the
local engine through which the request was received.
The command responder application will perform the appropriate protocol
operation, using access control, and will generate a response message to
be sent to the request's originator.

37. Command Responder Network Message Processing Security Command Model
Generator
Dispatcher
processPDU
processIncomingMsg
prepareDataElements
registerContext
EngineID
Receive get-request msg
Network
Send get-response msg
generateResponseMsg
prepareResponseMsg
processResponse
PDU

38. SNMP Applications: (cont.)
Notification Originator Applications:
These applications initiate asynchronous messages.
A notification originator application conceptually monitors a system for
particular events or conditions, and generates Trap and/or Inform
messages based on these events or conditions.
A notification originator must have a mechanism for determining where
to send messages, and what SNMP version and security parameters to
use when sending messages.
The particular mechanism used is implementation dependent.

39. SNMP Applications: (cont.)
Notification Receiver Applications:
These applications process asynchronous messages.
A notification receiver application listens for notification messages,
and generates response messages when a message containing an Inform
PDU is received.
These applications receive SNMP Notification messages from the
Dispatcher.
Before any messages can be received, the notification receiver must
register with the Dispatcher.
Once the notification receiver has registered with the Dispatcher,
messages are received using the processPdu abstract service interface.

40. SNMP Applications: (cont.)
Proxy Forwarder Applications:
They forward SNMP messages between entities.
Implementation of a proxy forwarder application is optional.
Proxy forwarder application forwards requests and/or notifications to
other SNMP engines according to the context, and irrespective of the
specific managed object types being accessed, and forwards the response
to such previously forwarded messages back to the SNMP engine from
which the original message was received.

41. SNMPv3 MIBs
The Management Information Base (MIB) contains data available to a
network management program.
MIBs are created by management agents so that each machine with an
agent will have an associated MIB.
The MIB is the definition of the data, or objects, that are stored in the agent
for the manager to access.
RFC 2273 defines three MIBs to support SNMPv3 applications:
The Management Target MIB.
The Notification MIB.
The Proxy MIB.

42. SNMPv3 MIBs (cont.) Management Target MIB:
The SNMP-TARGET-MIB module contains objects for defining management targets and includes a single group, the snmpTargetsObjects group.
A management target refers to a management entity that can be the recipient of messages generated by notification generators and proxy forwarders.
It consists of two tables:
snmpTargetAddrTable: It contains information about transport domains and addresses. It also contains an object, snmpTargetAddrTagList, which provides a mechanism for grouping entries.
snmpTargetParamsTable: It contains information about SNMP version and security information to be used when sending messages to particular transport domains and addresses.

43. SNMPv3 MIBs (cont.) Notification MIB:
The SNMP-NOTIFICATION-MIB module contains objects for the remote configuration of the parameters used by an SNMP entity for the generation of notifications, and includes a single group, snmpNotifyObjectsGroup.
The group consists of three tables:
snmpNotifyTable: It contains entries which select which entries in the snmpTargetAddrTable should be used for generating notifications, and the type of notifications to be generated.
snmpNotifyFilterProfileTable: It augments the snmpTargetAddrTable with an object which is used to associate a set of filters with a particular management target.
snmpNotifyFilterTable: It defines filters which are used to limit the number of notifications which are generated using particular management targets.

44. SNMPv3 MIBs (cont.) Proxy MIB:
It defines MIB objects that provide mechanisms to remotely configure the parameters used by an SNMP entity for proxy forwarding operations. The MIB includes a single group, snmpProxyObjectsGroup.
It contains a single table:
snmpProxyTable: It is used to define translations between management targets for use when forwarding messages.
It enables proxy forwarder to accept an incoming message, determine for each message the target or targets and construct the security parameters for the outgoing message.

45. SNMPv3 Security Models SNMPv3 defines two security-related models:
1. User-Based security model (USM):
It provides authentication and privacy (encryption) functions at the message level.
2. View-Based access control model (VACM):
It determines whether a given principal is allowed access to particular MIB objects to perform particular functions, and operates at the PDU level.
It uses a MIB that defines the access control policy for this agent, and makes it possible for remote configuration to be used.

46. SNMPv3 Security Models (cont.)
User-Based security model (USM):
The goals of this SNMP Security Model are as follows:
Provide for verification that each received SNMP message has not
been modified during its transmission through the network.
Provide for verification of the identity of the user on whose
behalf a received SNMP message claims to have been generated.
Provide for detection of received SNMP messages, which request or
contain management information, whose time of generation was not
recent.
Provide, when necessary, that the contents of each received SNMP
message are protected from disclosure.

47. SNMPv3 Security Models (cont.)
Security Services:
The security services necessary to support the goals of this SNMP Security Model are as follows:
Data Integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non-maliciously.
Data Origin Authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is corroborated.
Data Confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes.
Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted.

48. SNMPv3 Security Models (cont.)
View-Based access control model (VACM):
The VACM has five elements:
1. Groups:
A group is a set of zero or more <securityModel, security Name> tuples
on whose behalf SNMP management objects can be accessed. A group
defines the access rights afforded to all securityNames which belong
to that group.
2. Security Level:
Different access rights for members of a group can be defined for different levels of security, i.e., noAuthNoPriv, authNoPriv, and authPriv. The security Level identifies the level of security that will be assumed when checking for access rights.

49. SNMPv3 Security Models (cont.)
3. Contexts:
An SNMP context is a collection of management information accessible
by an SNMP entity. An item of management information may exist in
more than one context. An SNMP entity potentially has access to many
contexts.
4. MIB Views:
For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information in the management domain.
Access allowed for a group can be restricted in the desired manner by specifying a MIB view.

50. SNMPv3 Security Models (cont.)
5. Access Policy:
VACM enables an SNMP engine to be configured to enforce a particular set of access rights. Access determination depends on the following factors:
The principal making the access request.
The security level by which the request was communicated in an SNMP message.
The security model used for processing the request message.
The MIB context for the request.
The specific object instance for which access is requested.
The type of access requested (read, write, notify).

51. Compatibility with SNMPv2 and v1
SNMPv3 managers can monitor and control only SNMPv2/v3 agents.
SNMPv3 managers cannot monitor SNMPv1 agents.
A large percentage of products are using SNMPv2 or SNMPv3.
SNMPv2 and SNMPv3 are not as simple as SNMPv1 and require more powerful CPU, more memory, and other resources.
SNMPv2 and SNMPv3 have advantage of no transition to manage.
Can still use old management applications by using
1. Dual-Mode Agents
2. Dual-Mode Managers
3. Protocol Conversion Gateways