Simple Network Management Protocol
Contents 1 Overview and basic concepts 2 Management information base 3 Protocol details 4 Development and usage 4.1 Version 1 4.2 Version 2 4.3 SNMPv1 & SNMPv2c interoperability 4.3.1 Proxy agents 4.3.2 Bilingual network-management system 4.4 Version 3 5 Implementation issues 5.1 Autodiscovery 6 Resource indexing 7 Security implications 8 RFC references 9 See also 10 References 11 Further reading 12 External links Overview and basic concepts[edit] Principle of SNMP Communication In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes a software component called an agent which reports information via SNMP to the manager. An SNMP-managed network consists of three key components: Managed devices Agent – software which runs on managed devices Network management station (NMS) – software which runs on the manager A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidirectional (read and write) access to node-specific information. Managed devices exchange node-specific information with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including, but not limited to, routers, access servers, switches, cable modems, bridges, hubs, IP telephones, IP video cameras, computer hosts, and printers. An agent is a network-management software module that resides on a managed device. An agent has local knowledge of management information and translates that information to or from an SNMP-specific form. A network management station executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network. Management information base[edit] Main article: Management information base SNMP agents expose management data on the managed systems as variables. The protocol also permits active management tasks, such as configuration changes, through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. SNMP itself does not define which variables a managed system should offer. Rather, SNMP uses an extensible design which allows applications to define their own hierarchies. These hierarchies, are described as a management information base (MIB). MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2.0 (SMIv2, RFC 2578), a subset of ASN.1. Protocol details[edit] SNMP operates in the application layer of the Internet protocol suite. All SNMP messages are transported via User Datagram Protocol (UDP). The SNMP agent receives requests on UDP port 161. The manager may send requests from any available source port to port 161 in the agent. The agent response is sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests) on port 162. The agent may generate notifications from any available port. When used with Transport Layer Security or Datagram Transport Layer Security, requests are received on port 10161 and notifications are sent to port 10162.[3] SNMPv1 specifies five core protocol data units (PDUs). Two other PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and the Report PDU was added in SNMPv3. All SNMP PDUs are constructed as follows: IP header UDP header version community PDU-type request-id error-status error-index variable bindings The seven SNMP protocol data unit (PDU) types are as follows: GetRequest A manager-to-agent request to retrieve the value of a variable or list of variables. Desired variables are specified in variable bindings (values are not used). Retrieval of the specified variable values is to be done as an atomic operation by the agent. A Response with current values is returned. SetRequest A manager-to-agent request to change the value of a variable or list of variables. Variable bindings are specified in the body of the request. Changes to all specified variables are to be made as an atomic operation by the agent. A Response with (current) new values for the variables is returned. GetNextRequest A manager-to-agent request to discover available variables and their values. Returns a Response with variable binding for the lexicographically next variable in the MIB. The entire MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0. Rows of a table can be read by specifying column OIDs in the variable bindings of the request. GetBulkRequest Optimized version of GetNextRequest. A manager-to-agent request for multiple iterations of GetNextRequest. Returns a Response with multiple variable bindings walked from the variable binding or bindings in the request. PDU specific non-repeaters and max-repetitions fields are used to control response behavior. GetBulkRequest was introduced in SNMPv2. Response Returns variable bindings and acknowledgement from agent to manager for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error reporting is provided by error-status and error-index fields. Although it was used as a response to both gets and sets, this PDU was called GetResponse in SNMPv1. Trap Asynchronous notification from agent to manager. SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message. Includes current sysUpTime value, an OID identifying the type of trap and optional variable bindings. Destination addressing for traps is determined in an application-specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap. While in classic communication the client always actively requests information from the server, SNMP allows the additional use of so-called "traps". These are data packages that are sent from the SNMP agent to the manager without being explicitly requested InformRequest Acknowledged asynchronous notification. This PDU was introduced in SNMPv2 and was originally defined as manager to manager communication.[4] Later implementations have loosened the original definition to allow agent to manager communications.[5][6][7] Manager-to-manager notifications were already possible in SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery is not assured and dropped packets are not reported, delivery of a Trap was not guaranteed. InformRequest fixes this by sending back an acknowledgement on receipt.[6] RFC 1157 specifies that the SNMP protocol implementation must accept a
message of more than 484 bytes in length. In practice SNMP
implementations accept longer messages.[8]:1870 If implemented
correctly a SNMP message is discarded if the decoding of the message
fails and thus malformed SNMP requests are ignored. A decoded SNMP
request is then authenticated using the community string. If the
authentication fails, a trap is generated indicating an authentication
failure and the message is dropped.[8]:1871
SNMPv1 and SNMPv2 use communities to establish trust between managers
and agents. Most agents support three community names, one each for
read-only, read-write and trap. These three community strings control
different types of activities. The read-only community reads data,
such as the number of packets that have been transferred through the
ports of a router. The read-write community string is allowed to also
modify data values, such as the configuration of a router. The trap
community string allows the manager to receive asynchronous
notifications from the agent. SNMPv3 also uses community strings, but
allows for secure authentication and communication between SNMP
manager and agent.[9]
Development and usage[edit]
In practice, SNMP implementations often support multiple versions:
typically SNMPv1, SNMPv2c, and SNMPv3.[10][11]
Version 1[edit]
SNMP version 1 (SNMPv1) is the initial implementation of the SNMP
protocol. SNMPv1 operates over protocols such as User Datagram
Protocol (UDP),
Internet Protocol
RFC 1065 — Structure and identification of management information for TCP/IP-based internets RFC 1066 — Management information base for network management of TCP/IP-based internets RFC 1067 — A simple network management protocol These protocols were obsoleted by: RFC 1155 — Structure and identification of management information for TCP/IP-based internets RFC 1156 — Management information base for network management of TCP/IP-based internets RFC 1157 — A simple network management protocol After a short time, RFC 1156 (MIB-1) was replaced by the more often used: RFC 1213 — Version 2 of management information base (MIB-2) for network management of TCP/IP-based internets Version 1 has been criticized for its poor security.[13]
Authentication
An SNMPv2 NMS issues a command intended for an SNMPv1 agent. The NMS sends the SNMP message to the SNMPv2 proxy agent. The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged. GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent. The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS. Bilingual network-management system[edit] Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP. Version 3[edit] This section is in a list format that may be better presented using prose. You can help by converting this section to prose, if appropriate. Editing help is available. (September 2016) Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks much different due to new textual conventions, concepts, and terminology.[1] SNMPv3 primarily added security and remote configuration enhancements to SNMP.[15] Due to lack of security with the use of SNMP, network administrators were using other means, such as telnet and SSH for configuration, accounting, and fault management. SNMPv3 addresses issues related to the large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management. SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities. SNMPv3 provides a secure environment for the management of systems covering the following: Identification of SNMP entities to facilitate communication only between known SNMP entities – Each SNMP entity has an identifier called the SNMPEngineID, and SNMP communication is possible only if an SNMP entity knows the identity of its peer. Traps and Notifications are exceptions to this rule. Support for security models – A security model may define the security policy within an administrative domain or an intranet. SNMPv3 contains the specifications for USM (User-based Security Model). Definition of security goals where the goals of message authentication service include protection against the following: Modification of Information – Protection against some unauthorized SNMP entity altering in-transit messages generated by an authorized principal. Masquerade – Protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations. Message Stream Modification – Protection against messages getting maliciously re-ordered, delayed, or replayed to effect unauthorized management operations. Disclosure – Protection against eavesdropping on the exchanges between SNMP engines. Specification for USM – USM (User-based Security Model) consists of the general definition of the following communication mechanisms available: Communication without authentication and privacy (NoAuthNoPriv). Communication with authentication and without privacy (AuthNoPriv). Communication with authentication and privacy (AuthPriv). Definition of different authentication and privacy protocols –
Currently, the
MD5
SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts, namely notification originators and proxy forwarders. SNMPv3 defines a number of security-related capabilities. The initial specifications defined the USM and VACM, which were later followed by a transport security model that provided support for SNMPv3 over SSH and SNMPv3 over TLS and DTLS. USM (User-based Security Model) provides authentication and privacy (encryption) functions and operates at the message level. VACM (View-based Access Control Model) determines whether a given principal is allowed access to a particular MIB object to perform specific functions and operates at the PDU level. TSM (Transport Security Model) provides a method for authenticating and encrypting messages over external security channels. Two transports, SSH and TLS/DTLS, have been defined that make use of the TSM specification. Security has been the biggest weakness of SNMP since the beginning.
Authentication
Confidentiality –
Encryption
As of 2004[update] the
IETF
This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (April 2010) (Learn how and when to remove this template message) SNMP by itself is simply a protocol for collecting and organizing information about managed devices (network and device monitoring), and modifying that information on these devices, causing change in their behavior (network management). Most toolsets implementing SNMP offer some form of discovery mechanism, a standardized collection of data common to most platforms and devices, to get the implantation of SNMP in a network started. One of these features is often a form of automatic discovery, where new devices discovered in the network are polled automatically. For SNMPv1 and SNMPv2c, this presents a security risk, in that SNMP read communities will be broadcast in clear-text to the target device. SNMPv3 mitigates this risk, however it does not protect against traffic analysis and potential network topology discovery by an adversary. While security requirements and risk profiles vary from organization to organization, care should be taken when using a feature like automatic discovery, especially in mixed-tenant datacenters, server hosting and colocation facilities, and similar environments. Resource indexing[edit] This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (April 2010) (Learn how and when to remove this template message) Modular devices may dynamically increase or decrease their SNMP indices (a.k.a. instances) whenever slotted hardware is added or removed. Although this is most common with hardware, virtual interfaces have the same effect. Index values are typically assigned at boot time and remain fixed until the next reboot. Hardware or virtual entities added while the device is 'live' may have their indices assigned at the end of the existing range and possibly reassigned at the next reboot. Network inventory and monitoring tools need to have the device update capability by properly reacting to the cold start trap from the device reboot in order to avoid corruption and mismatch of polled data. Index assignments for a SNMP device instance may change from poll to poll mostly as a result of changes initiated by the system administrator. If information is needed for a particular interface, it is imperative to determine the SNMP index before retrieving the data needed. Generally, a description table like ifDescr will map a user friendly name like Serial 0/1 (Blade 0, port 1) to an SNMP index. However, this is not necessarily the case for a specific SNMP value, and can be arbitrary for an SNMP implementation. Security implications[edit] This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (December 2015) (Learn how and when to remove this template message) Because SNMP is designed to allow administrators to monitor and
configure network devices remotely it can also be used to penetrate a
local area network (LAN). If SNMP is not used in a network it should
be turned off, because aside from creating a vulnerability it will
consume available network bandwidth and needlessly use
CPU
RFC 1155 (STD 16) — Structure and Identification of Management Information for the TCP/IP-based Internets RFC 1156 (Historic) — Management Information Base for Network Management of TCP/IP-based internets RFC 1157 (Historic) — A Simple Network Management Protocol (SNMP) RFC 1213 (STD 17) — Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC 1452 (Informational) — Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework (Obsoleted by RFC 1908) RFC 1901 (Experimental) — Introduction to Community-based SNMPv2 RFC 1902 (Draft Standard) — Structure of Management Information for SNMPv2 (Obsoleted by RFC 2578) RFC 1908 (Standards Track) — Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework RFC 2570 (Informational) — Introduction to Version 3 of the Internet-standard Network Management Framework (Obsoleted by RFC 3410) RFC 2578 (STD 58) — Structure of Management Information Version 2 (SMIv2) RFC 3410 (Informational) — Introduction and Applicability Statements for Internet Standard Management Framework STD 62 RFC 3411 — An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks
RFC 3412 — Message Processing and Dispatching for the
Simple Network Management Protocol
RFC 3430 (Experimental) — Simple Network Management
Protocol (SNMP) over
Transmission Control Protocol
See also[edit] AgentX, a subagent protocol for SNMP CMIP over TCP/IP (CMOT) Common management information protocol (CMIP), a management protocol by ISO/OSI used by telecommunications devices Common management information service (CMIS) IEC 62379 Net-SNMP, an open source reference implementation of SNMP Netconf, a protocol which is an XML-based configuration protocol for network equipment Network monitoring comparison Object identifier (OID) Remote monitoring (RMON) Simple Gateway Monitoring Protocol (SGMP), an obsolete protocol replaced by SNMP SNMP simulator References[edit] ^ a b c Douglas R. Mauro & Kevin J. Schmidt. (2001). Essential
SNMP (1st ed.). Sebastopol, CA: O’Reilly & Associates.
^ An Architecture for Describing Simple Network Management Protocol
(SNMP) Management Frameworks. doi:10.17487/RFC3411. RFC 3411.
https://tools.ietf.org/html/rfc3411.
^ RFC 6353 Section 10
^ J. Case; K. McCloghrie; M. Rose; S. Waldbusser (April 1993). "RFC
1448 – Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)". Internet Engineering Task Force. An
InformRequest-PDU is generated and transmitted at the request an
application in a SNMPv2 entity acting in a manager role, that wishes
to notify another application (in a SNMPv2 entity also acting in a
manager role) of information in the MIB View of a party local to the
sending application.
^ D. Levi; P. Meyer; B. Stewart (April 1999). "RFC 2573 – SNMP
Applications". Internet Engineering Task Force.
^ a b "SNMP Inform Requests". Cisco. Retrieved 2011-12-09.
^ "Understanding the SNMP Implementation in JUNOS Software". Juniper
Networks. Retrieved 2013-02-11.
^ a b c d e Harold F. Tipton & Micki Krause (2007). Information
Security Management Handbook, Sixth Edition. CRC Press.
ISBN 9780849374951. CS1 maint: Uses authors parameter (link)
^ Douglas Mauro & Kevin Schmidt (2005). Information Security
Management Handbook, Sixth EditioEssential SNMP:
Help for System and
Network Administrators. O'Reilly Media, Inc. pp. 21–22.
ISBN 9780596552770. CS1 maint: Uses authors parameter (link)
^ a b c Stuart Jacobs (2015). Engineering Information Security: The
Application of Systems Engineering Concepts to Achieve Information
Assurance. John Wiley & Sons. p. 367.
ISBN 9781119104797.
^ RFC 3584 "Coexistence between Version 1, Version 2, and Version
3 of the Internet-standard Network Management Framework"
^ Wiley, John (2015-12-01). Engineering Information Security: The
Application of Systems Engineering Concepts to Achieve Information
Assurance. p. 366. Retrieved 2017-09-14.
^ a b "Security in SNMPv3 versus SNMPv1 or v2c" (PDF). Archived from
the original (PDF) on 2013-04-29.
^ a b c "RFC Search Detail: Standards Track snmpv2 RFCs". The RFC
Editor. Retrieved 2014-02-24.
^ In This Issue: SNMP Version 3 The Simple Times ISSN 1060-6084
^ David Zeltserman (1999). A Practical Guide to SNMPv3 and Network
Management. Upper Saddle River, NJ: Prentice Hall PTR.
^ "SNMPv3".
Cisco
Further reading[edit] Douglas Mauro, Kevin Schmidt (2005). Essential SNMP, Second Edition. O'Reilly Media. p. 462. ISBN 0596008406. William Stallings (1999). SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Addison Wesley Longman, Inc. p. 619. ISBN 0201485346. External links[edit] Wikiversity has learning resources about Simple Network Management Protocol
Simple Network Management Protocol
|