Agenda

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 TypePurpose 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 TypeIndication 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 get-request set-request set-request trap trap get-response get-response 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 RFCDescription 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 TypePurpose 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 NameProvides 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 NamePURPOSE 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 NamePURPOSE 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 1998. 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 thegoals, 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 plusthe 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) 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(s) Command Generator Notification Receiver Proxy Forwarder Command Responder Notification Originator Other ApplicationExample 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 Message Processing Model Security Model Command Generator 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 Message Processing Model Security Model Command 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).