View source for Simple Network Management Protocol

{{Short description|Computer network management and monitoring protocol}}
{{Use American English|date=September 2020}}

{{Infobox networking protocol
| name          = SNMPv3 STD0062
| rfcs         = 3411–3418
| ports         = 161, 162 (Trap)
| osilayer      = [[Application layer|Application]]
}}
{{Infobox networking protocol
| name          = Secure SNMP
| rfcs         = 6353
| ports         = 10161, 10162 (Trap)
| osilayer      = [[Application layer|Application]]
}}
{{IPstack}}

'''Simple Network Management Protocol''' ('''SNMP''') is an [[Internet Standard]] protocol for collecting and organizing information about managed devices on [[Internet Protocol|IP]] networks and for modifying that information to change device behavior. Devices that typically support SNMP include [[cable modem]]s, [[Router (computing)|routers]], [[network switch]]es, servers, workstations, printers, and more.<ref name="ESNMP">{{cite book |author=Douglas R. Mauro & Kevin J. Schmidt. |year=2001 |title=Essential SNMP |edition=1st |location=Sebastopol, CA |publisher=O'Reilly & Associates}}</ref>

SNMP is widely used in [[network management]] for [[network monitoring]].  SNMP exposes management data in the form of variables on the managed systems organized in a [[management information base]] (MIB), which describes the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications.

Three significant versions of SNMP have been developed and deployed. SNMPv1 is the original version of the protocol. More recent versions, SNMPv2c and SNMPv3, feature improvements in performance, flexibility and security.

SNMP is a component of the [[Internet Protocol Suite]] as defined by the [[Internet Engineering Task Force]] (IETF). It consists of a set of [[Technical standard|standards]] for network management, including an [[application layer]] protocol, a database [[logical schema|schema]], and a set of [[data object]]s.<ref name="RFC 3411">{{Cite IETF |rfc=3411 |title=An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks}}</ref>

== Overview and basic concepts ==
[[File:SNMP communication principles diagram.PNG|thumb|Principle of SNMP Communication|500px]]
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'' that reports information via SNMP to the manager.

An SNMP-managed network consists of three key components:
* Managed devices
* [[Software agent|Agent]]{{snd}}software that runs on managed devices
* [[Network management station]] (NMS){{snd}}software that 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, [[router (computing)|router]]s, [[access server]]s, [[Network switch|switches]], [[cable modems]], [[Network bridge|bridge]]s, [[Ethernet hub|hub]]s, [[IP telephone]]s, [[IP video camera]]s, computer [[Host (network)|host]]s, and [[Computer printer|printer]]s.

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 ==
{{Main|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 that 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 identifier]]s (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, {{IETF RFC|2578}}), a subset of [[ASN.1]].

== Protocol details ==
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 (''[[#Trap|Traps]]'' and ''[[#InformRequest|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.<ref>{{IETF RFC|6353}} Section 10</ref>

SNMPv1 specifies five core [[protocol data unit]]s (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:

{| class="wikitable"
|-
| IP header
| UDP header
| version
| community
| PDU-type
| request-id
| error-status
| error-index
| variable bindings
|}

The seven SNMP PDU types, as identified by the ''PDU-type'' field, 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 (the value field is not used). Retrieval of the specified variable values is to be done as an [[atomic operation]] by the agent.{{Citation needed|date=May 2025}} 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.{{Ref RFC|1157|p=26|quote=Each variable assignment specified by the SetRequest-PDU should be effected as if simultaneously set with respect to all other assignments specified in the same message.}} 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 [[Lexicographical order|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 : A manager-to-agent request for multiple iterations of ''GetNextRequest''. An optimized version 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.
; {{Visible anchor|Trap}}: Asynchronous notification from agent to manager. While in other SNMP communication, the manager actively requests information from the agent, these are PDUs that are sent from the agent to the manager without being explicitly requested. SNMP [[#Trap|Traps]] enable an agent to notify the management station of significant events by way of an unsolicited SNMP message. Trap PDUs include 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''.
; {{Visible anchor|InformRequest}}: Acknowledged asynchronous notification. This PDU was introduced in SNMPv2 and was originally defined as ''manager to manager'' communication.<ref>{{Cite web |url=https://tools.ietf.org/html/rfc1448#page-27 |title=RFC 1448 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) |publisher=Internet Engineering Task Force |quote=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. |author1=J. Case |author2=K. McCloghrie |author3=M. Rose |author4=S. Waldbusser |date=April 1993|doi=10.17487/RFC1448 }}</ref> Later implementations have loosened the original definition to allow ''agent to manager'' communications.<ref>{{Cite web |url=https://tools.ietf.org/html/rfc2573#section-3.3 |title=RFC 2573 – SNMP Applications |publisher=Internet Engineering Task Force |author1=D. Levi |author2=P. Meyer |author3=B. Stewart |date=April 1999|doi=10.17487/RFC2573 }}</ref><ref name="cisco_a">{{Cite web |url=http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/snmpinfm.html |title=SNMP Inform Requests |publisher=Cisco |access-date=2011-12-09}}</ref><ref>{{Cite web |url=https://www.juniper.net/techpubs/software/junos-security/junos-security10.2/mib-srx5600-srx5800-service-gateway/topic-21511.html |title=Understanding the SNMP Implementation in JUNOS Software |publisher=Juniper Networks |access-date=2013-02-11}}</ref> 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 as an acknowledgement is returned on receipt.<ref name="cisco_a" />

{{anchor|Community string}}{{IETF RFC|1157}} specifies that an SNMP implementation must accept a message of at least 484 bytes in length. In practice, SNMP implementations accept longer messages.<ref name="Tipton">{{Cite book|title= Information Security Management Handbook, Sixth Edition|author1=Harold F. Tipton |author2=Micki Krause |publisher= CRC Press|year=2007 |isbn= 9780849374951}}</ref>{{rp|1870}} If implemented correctly, an SNMP message is discarded if the decoding of the message fails and thus malformed SNMP requests are ignored. A successfully 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.<ref name="Tipton"/>{{rp|1871}}

SNMPv1 and SNMPv2c 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 applies to ''get'' requests. The read-write community string applies to ''set'' requests. The trap community string applies to receipt of ''traps''. SNMPv3 also uses community strings, but allows for secure authentication and communication between SNMP manager and agent.<ref>{{Cite book|title= Information Security Management Handbook, Sixth EditioEssential SNMP: Help for System and Network Administrators|author1=Douglas Mauro |author2=Kevin Schmidt |publisher= O'Reilly Media, Inc.|year=2005 |isbn= 9780596552770|pages=21–22}}</ref>

== Protocol versions ==
In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3.<ref name="Jacobs">{{Cite book|title= Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information Assurance|author =Stuart Jacobs |publisher= John Wiley & Sons|year=2015 |isbn=  9781119104797|pages=367}}</ref><ref>{{IETF RFC|3584}} "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework"</ref>

=== Version 1 ===
SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. The design of SNMPv1 was done in the 1980s by a group of collaborators who viewed the officially sponsored OSI/IETF/NSF ([[National Science Foundation]]) effort (HEMS/CMIS/CMIP) as both unimplementable in the computing platforms of the time as well as potentially unworkable. SNMP was approved based on a belief that it was an interim protocol needed for taking steps towards large-scale deployment of the Internet and its commercialization.

The first [[Request for Comments]] (RFCs) for SNMP, now known as SNMPv1, appeared in 1988:
* {{IETF RFC|1065}}&nbsp;— Structure and identification of management information for TCP/IP-based internets
* {{IETF RFC|1066}}&nbsp;— Management information base for network management of TCP/IP-based internets
* {{IETF RFC|1067}}&nbsp;— A simple network management protocol

In 1990, these documents were superseded by:
* {{IETF RFC|1155}}&nbsp;— Structure and identification of management information for TCP/IP-based internets
* {{IETF RFC|1156}}&nbsp;— Management information base for network management of TCP/IP-based internets
* {{IETF RFC|1157}}&nbsp;— A simple network management protocol

In 1991, {{IETF RFC|1156}} (MIB-1) was replaced by the more often used:
* {{IETF RFC|1213}}&nbsp;— Version 2 of management information base (MIB-2) for network management of TCP/IP-based internets

SNMPv1 is widely used and is the [[De facto standard|de facto]] network management protocol in the Internet community.<ref>{{cite book |last1=Wiley |first1=John |title=Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information Assurance |date=2015-12-01 |page=366 |publisher=John Wiley & Sons |url=https://books.google.com/books?id=6i1cCwAAQBAJ&q=snmpv1+is+obsolete&pg=PA366 |access-date=2017-09-14|isbn=9781119104711 }}</ref>

SNMPv1 may be carried by [[transport layer]] protocols such as User Datagram Protocol (UDP), OSI [[Connectionless-mode Network Service]] (CLNS), AppleTalk [[Datagram Delivery Protocol]] (DDP), and Novell [[Internetwork Packet Exchange]] (IPX).

Version 1 has been criticized for its poor security.<ref name="aethis">{{cite web |title=Security in SNMPv3 versus SNMPv1 or v2c |url=http://www.aethis.com/solutions/snmp_research/snmpv3_vs_wp.pdf |archive-url=https://web.archive.org/web/20130429201847/http://www.aethis.com/solutions/snmp_research/snmpv3_vs_wp.pdf |archive-date=2013-04-29}}</ref> The specification does, in fact, allow room for custom authentication to be used, but widely used implementations "support only a trivial authentication service that identifies all SNMP messages as authentic SNMP messages."<ref>{{IETF RFC|1157}}</ref> The security of the messages, therefore, becomes dependent on the security of the channels over which the messages are sent. For example, an organization may consider their internal network to be sufficiently secure that no encryption is necessary for its SNMP messages. In such cases, the ''community name'', which is transmitted in [[cleartext]], tends to be viewed as a de facto password, in spite of the original specification.

=== Version 2 ===
SNMPv2, defined by {{IETF RFC|1441}} and {{IETF RFC|1452}}, revises version 1 and includes improvements in the areas of performance, security and manager-to-manager communications. It introduced ''GetBulkRequest'', an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request. The new party-based security system introduced in SNMPv2, viewed by many as overly complex, was not widely adopted.<ref name="aethis"/>  This version of SNMP reached the Proposed Standard level of maturity, but was deemed obsolete by later versions.<ref name="rfced">{{cite web|url=http://www.rfc-editor.org/search/rfc_search_detail.php?pubstatus%5b%5d=Standards+Track&std_trk=Any&pub_date_type=any&wg_acronym=snmpv2 |title=RFC Search Detail: Standards Track snmpv2 RFCs|publisher=The RFC Editor |access-date=2014-02-24}}</ref>

''Community-Based Simple Network Management Protocol version 2'', or ''SNMPv2c'', is defined in {{IETF RFC|1901}}–{{IETF RFC|1908}}.  SNMPv2c comprises SNMPv2 ''without'' the controversial new SNMP v2 security model, using instead the simple community-based security scheme of SNMPv1. This version is one of relatively few standards to meet the IETF's Draft Standard maturity level, and was widely considered the ''[[de facto]]'' SNMPv2 standard.<ref name="rfced"/>  It was later restated as part of SNMPv3.<ref>{{IETF RFC|3416}}</ref>

''User-Based Simple Network Management Protocol version 2'', or ''SNMPv2u'', is defined in {{IETF RFC|1909}}–{{IETF RFC|1910}}. This is a compromise that attempts to offer greater security than SNMPv1, but without incurring the high complexity of SNMPv2. A variant of this was commercialized as ''SNMP v2*'', and the mechanism was eventually adopted as one of two security frameworks in SNMP v3.<ref>{{Citation |title=SNMPv3 -- User Security Model |url=http://www.drdobbs.com/snmpv3-user-security-model/199100972 |access-date=2019-03-09 |publisher=Dr. Dobbs}}</ref>

==== 64-bit counters ====
SNMP version 2 introduces the option for 64-bit data counters. Version 1 was designed only with 32-bit counters, which can store integer values from zero to 4.29 billion (precisely {{val|4,294,967,295}}). A 32-bit version 1 counter cannot store the maximum speed of a 10-gigabit or larger interface, expressed in bits per second. Similarly, a 32-bit counter tracking statistics for a 10-gigabit or larger interface can roll over back to zero again in less than one minute, which may be a shorter time interval than a counter is polled to read its current state. This would result in lost or invalid data due to the undetected value rollover and corruption of trend-tracking data.

The 64-bit version 2 counter can store values from zero to 18.4 quintillion (precisely 18,446,744,073,709,551,615) and so is currently unlikely to experience a counter rollover between polling events. For example, 1.6 [[terabit Ethernet]] is predicted to become available by 2025. A 64-bit counter incrementing at a rate of 1.6 trillion bits per second would be able to retain information for such an interface without rolling over for 133 days.

=== SNMPv1 and SNMPv2c interoperability ===
SNMPv2c is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2c messages use a different header and different protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2c also uses two protocol operations that are not specified in SNMPv1. To overcome incompatibility, {{IETF RFC|3584}} defines two SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems.

==== Proxy agents ====
An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1-managed devices. When an SNMPv2 NMS issues a command intended for an SNMPv1 agent, it sends it to the SNMPv2 proxy agent instead. The proxy agent forwards <code>Get</code>, <code>GetNext</code>, and <code>Set</code> messages to the SNMPv1 agent unchanged. GetBulk messages are converted by the proxy agent to <code>GetNext</code> messages and then are forwarded to the SNMPv1 agent. Additionally, the proxy agent receives and maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

==== Bilingual network-management system ====
Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application 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 ===
{{prose|section|date=September 2016}}
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks very different due to new textual conventions, concepts, and terminology.<ref name="ESNMP"/> The most visible change was to define a secure version of SNMP, by adding security and remote configuration enhancements to SNMP.<ref name=simpletime>[http://www.simple-times.org/pub/simple-times/issues/5-1.html In This Issue: SNMP Version 3] {{Webarchive|url=https://web.archive.org/web/20170727124237/https://www.simple-times.org/pub/simple-times/issues/5-1.html |date=2017-07-27 }} [http://www.simple-times.org/ The Simple Times] {{ISSN|1060-6084}}</ref> The security aspect is addressed by offering both strong authentication and data encryption for privacy. For the administration aspect, SNMPv3 focuses on two parts, namely notification originators and proxy forwarders. The changes also facilitate remote configuration and administration of the SNMP entities, as well as addressing issues related to the large-scale deployment, accounting, and fault management.

Features and enhancements included:
* 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 a user-based security model (USM).
* 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 [[Data in transit|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 affect unauthorized management operations.
** Disclosure – Protection against eavesdropping on the exchanges between SNMP engines.
* Specification for USM – USM 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 – MD5, SHA and HMAC-SHA-2<ref>RFC 7860</ref> authentication protocols and the CBC_DES and CFB_AES_128 privacy protocols are supported in the USM.
* Definition of a discovery procedure – To find the SNMPEngineID of an SNMP entity for a given transport address and transport endpoint address.
* Definition of the time synchronization procedure – To facilitate authenticated communication between the SNMP entities.
* Definition of the SNMP framework MIB – To facilitate remote configuration and administration of the SNMP entity.
* Definition of the USM MIBs – To facilitate remote configuration and administration of the security module.
* Definition of the view-based access control model (VACM) MIBs – To facilitate remote configuration and administration of the access control module.

Security was one of the biggest weaknesses of SNMP until v3. Authentication in SNMP Versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a manager and agent.<ref name="ESNMP"/> Each SNMPv3 message contains security parameters that are encoded as an octet string. The meaning of these security parameters depends on the security model being used.<ref>{{cite book |author=David Zeltserman |year=1999 |title=A Practical Guide to SNMPv3 and Network Management |location=Upper Saddle River, NJ |publisher=Prentice Hall PTR}}</ref> The security approach in v3 targets:<ref name=cisco>{{cite web |url=http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html |title=SNMPv3 |publisher=Cisco Systems |archive-url=https://web.archive.org/web/20110719232546/http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html |archive-date=2011-07-19 |url-status=dead }}</ref>
* Confidentiality – [[Encryption]] of packets to prevent snooping by an unauthorized source.
* Integrity – [[Message integrity]] to ensure that a packet has not been tampered with while in transit, including an optional packet replay protection mechanism.
* [[Authentication]] – to verify that the message is from a valid source.

v3 also defines the USM and VACM, which were later followed by a transport security model (TSM) 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.

{{As of|2004}} the [[IETF]] recognizes ''Simple Network Management Protocol version 3'' as defined by {{IETF RFC|3411}}–{{IETF RFC|3418}}<ref name=snmpv3>{{cite web |url=http://www.ibr.cs.tu-bs.de/projects/snmpv3/ |title=SNMP Version 3 |publisher=Institute of Operating Systems and Computer Networks |access-date=2010-05-07}}</ref> (also known as STD0062) as the current standard version of SNMP. The [[IETF]] has designated SNMPv3 a full [[Internet standard]],<ref>[http://www.rfc-editor.org/categories/rfc-standard.html RFC Editor] {{webarchive|url=https://web.archive.org/web/20071029103140/http://www.rfc-editor.org/categories/rfc-standard.html |date=2007-10-29 }} List of current Internet Standards (STDs)</ref> the highest [[IETF RFC#Status|maturity level]] for an RFC. It considers earlier versions to be obsolete (designating them variously ''Historic'' or ''Obsolete'').<ref name="rfced"/>

== Implementation issues ==
SNMP's powerful write capabilities, which would allow the configuration of network devices, are not being fully utilized by many vendors, partly because of a lack of security in SNMP versions before SNMPv3, and partly because many devices simply are not capable of being configured via individual MIB object changes.

Some SNMP values (especially tabular values) require specific knowledge of table indexing schemes, and these index values are not necessarily consistent across platforms. This can cause correlation issues when fetching information from multiple devices that may not employ the same table indexing scheme (for example, fetching disk utilization metrics, where a specific disk identifier is different across platforms.)<ref>{{Cite web | url=http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/40700-snmp-ifIndex40700.html | title=Understanding Table Index Values in SNMP}}</ref>

Some major equipment vendors tend to over-extend their proprietary [[command line interface]] (CLI) centric configuration and control systems.<ref>{{cite web|url=http://www.snmp.com/conferences/ |title=SNMP Research presentations in favor of standards-based management over proprietary CLIs |publisher=SNMP Research |access-date=2010-10-12}}</ref>{{Failed verification|date=November 2010}}

In February 2002 the [[Carnegie Mellon Software Engineering Institute]] (CM-SEI) Computer Emergency Response Team Coordination Center (CERT-CC) issued an Advisory on SNMPv1,<ref>{{citation |url=http://lwn.net/2002/0214/a/cert-snmp.php3 |title=CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations}}</ref> after the [[Oulu University Secure Programming Group]] conducted a thorough analysis of SNMP message handling. Most SNMP implementations, regardless of which version of the protocol they support, use the same program code for decoding [[protocol data units]] (PDU) and problems were identified in this code. Other problems were found with decoding SNMP trap messages received by the SNMP management station or requests received by the SNMP agent on the network device. Many vendors had to issue patches for their SNMP implementations.<ref name="Tipton"/>{{rp|1875}}

== Security implications ==

=== Using SNMP to attack a network ===
Because SNMP is designed to allow administrators to monitor and configure network devices remotely, it can also be used to penetrate a network. A significant number of software tools can scan the entire network using SNMP; therefore, mistakes in the configuration of the read-write mode can make a network susceptible to attacks.<ref name="Mason">{{Cite book|title= Cisco Secure Internet Security Solutions|author1=Andrew G. Mason |author2=Mark J. Newcomb |publisher= Cisco Press|year=2001 |isbn= 9781587050169}}</ref>{{rp|52}}

In 2001, [[Cisco]] released information that indicated that, even in read-only mode, the SNMP implementation of [[Cisco IOS]] is vulnerable to certain [[denial of service]] attacks. These security issues can be fixed through an IOS upgrade.<ref>{{Cite book|title= Cisco Secure Internet Security Solutions|url= https://archive.org/details/ciscosecureinter00maso|url-access= limited|author1=Andrew G. Mason |author2=Mark J. Newcomb |publisher= Cisco Press|year=2001 |isbn= 9781587050169|pages=[https://archive.org/details/ciscosecureinter00maso/page/n51 52]}}</ref>

If SNMP is not used in a network, it should be disabled in network devices. When configuring SNMP read-only mode, close attention should be paid to the configuration of the [[access control]] and from which IP addresses SNMP messages are accepted. If the SNMP servers are identified by their IP addresses, SNMP is only allowed to respond to these IPs and SNMP messages from other IP addresses would be denied. However, [[IP address spoofing]] remains a security concern.<ref name="Mason"/>{{rp|54}}

=== Authentication ===
SNMP is available in different versions, and each version has its own security issues. SNMP v1 sends passwords in [[plaintext]] over the network. Therefore, passwords can be read with [[packet sniffing]]. SNMP v2 allows [[password hashing]] with [[MD5]], but this has to be configured. Virtually all [[network management software]] support SNMP v1, but not necessarily SNMP v2 or v3. SNMP v2 was specifically developed to provide [[data security]], that is [[authentication]], [[privacy]] and [[authorization]], but only SNMP version 2c gained the endorsement of the [[Internet Engineering Task Force]] (IETF), while versions 2u and 2* failed to gain IETF approval due to security issues. SNMP v3 uses MD5, [[Secure Hash Algorithm]] (SHA) and keyed algorithms to offer protection against unauthorized data modification and [[spoofing attack]]s. If a higher level of security is needed the [[Data Encryption Standard]] (DES) can be optionally used in the [[cipher block chaining]] mode. SNMP v3 is implemented on Cisco IOS since release 12.0(3)T.<ref name="Mason"/>{{rp|52}}

SNMPv3 may be subject to [[Brute force attack|brute force]] and [[dictionary attack]]s for guessing the authentication keys, or encryption keys, if these keys are generated from short (weak) passwords or passwords that can be found in a dictionary. SNMPv3 allows both providing random uniformly distributed cryptographic keys and generating cryptographic keys from a password supplied by the user. The risk of guessing authentication strings from hash values transmitted over the network depends on the [[cryptographic hash function]] used and the length of the hash value. SNMPv3 uses the [[HMAC]]-[[SHA-2]] [[authentication protocol]] for the User-based Security Model (USM).<ref name="RFC7630">{{cite IETF |RFC=7630 |title=HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3}}</ref> SNMP does not use a more secure [[challenge-handshake authentication protocol]]. SNMPv3 (like other SNMP protocol versions) is a [[stateless protocol]], and it has been designed with a minimal amount of interactions between the agent and the manager. Thus introducing a challenge-response handshake for each command would impose a burden on the agent (and possibly on the network itself) that the protocol designers deemed excessive and unacceptable.{{Citation needed|date=April 2017}}

The security deficiencies of all SNMP versions can be mitigated by [[IPsec]] authentication and confidentiality mechanisms.{{Citation needed|date=June 2020}} SNMP also may be carried securely over [[Datagram Transport Layer Security]] (DTLS).<ref name="Jacobs"/>

Many SNMP implementations include a type of automatic discovery where a new network component, such as a switch or router, is discovered and polled automatically. In SNMPv1 and SNMPv2c, this is done through a ''community string'' that is transmitted in clear-text to other devices.<ref name="Jacobs"/> Clear-text passwords are a significant security risk. Once the community string is known outside the organization, it could become the target for an attack. To alert administrators of other attempts to glean community strings, SNMP can be configured to pass community-name authentication failure traps.<ref name="Mason"/>{{rp|54}} If SNMPv2 is used, the issue can be avoided by enabling password encryption on the SNMP agents of network devices.

The common default configuration for community strings are "public" for read-only access and "private" for read-write.<ref name="Tipton"/>{{rp|1874}} Because of the well-known defaults, SNMP topped the list of the [[SANS Institute]]'s Common Default Configuration Issues and was number ten on the SANS Top 10 Most Critical Internet Security Threats for the year 2000.<ref>{{Cite web | url=http://www.sans.org/top20/2000/ | title=SANS Institute - CIS Critical Security Controls}}</ref> System and network administrators frequently do not change these configurations.<ref name="Tipton"/>{{rp|1874}}

Whether it runs over TCP or UDP, SNMPv1 and v2 are vulnerable to [[IP spoofing]] attacks. With spoofing, attackers may bypass device access lists in agents that are implemented to restrict SNMP access. SNMPv3 security mechanisms, such as USM or TSM, can prevent spoofing attacks.

== See also ==
* [[Agent Extensibility Protocol]] (AgentX) – Subagent protocol for SNMP
* [[Common Management Information Protocol]] (CMIP) – Management protocol by ISO/OSI used by telecommunications devices
* [[Common Management Information Service]] (CMIS)
* [[Comparison of network monitoring systems]]
* {{annotated link|IEC 62379}}
* [[Net-SNMP]] – Open source reference implementation of SNMP
* [[NETCONF]] – Protocol that is an XML-based configuration protocol for network equipment
* [[Remote Network Monitoring]] (RMON)
* [[Simple Gateway Monitoring Protocol]] (SGMP) – Obsolete protocol replaced by SNMP
* {{annotated link|SNMP simulator}}

== References ==
{{Reflist}}

== Further reading ==
* {{Cite book
| publisher = O'Reilly Media
| isbn = 978-0596008406 
| author1 = Douglas Mauro
| author2 = Kevin Schmidt
| title = Essential SNMP
| edition = Second
| year = 2005
}}
* {{Cite book
| publisher = Addison Wesley Longman, Inc
| isbn = 978-0201485349
| author = William Stallings
| title = SNMP, SNMPv2, SNMPv3, and RMON 1 and 2
| year = 1999
| url = https://archive.org/details/snmpsnmpv2snmpv30000stal/page/619
}}
* {{Cite book
| publisher = Prentice Hall
| isbn = 0-13-451659-1
| author = Marshall T. Rose
| title = The Simple Book
| year = 1996
}}

* {{IETF RFC|1155}} (STD 16)&nbsp;— ''Structure and Identification of Management Information for the TCP/IP-based Internets''
* {{IETF RFC|1156}} (Historic)&nbsp;— ''Management Information Base for Network Management of TCP/IP-based internets''
* {{IETF RFC|1157}} (Historic)&nbsp;— ''A Simple Network Management Protocol (SNMP)''
* {{IETF RFC|1213}} (STD 17)&nbsp;— ''Management Information Base for Network Management of TCP/IP-based internets: MIB-II''
* {{IETF RFC|1452}} (Informational)&nbsp;— ''Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework'' (Obsoleted by {{IETF RFC|1908}})
* {{IETF RFC|1901}} (Experimental)&nbsp;— ''Introduction to Community-based SNMPv2''
* {{IETF RFC|1902}} (Draft Standard)&nbsp;— ''Structure of Management Information for SNMPv2'' (Obsoleted by {{IETF RFC|2578}})
* {{IETF RFC|1908}} (Standards Track)&nbsp;— ''Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework''
* {{IETF RFC|2570}} (Informational)&nbsp;— ''Introduction to Version 3 of the Internet-standard Network Management Framework '' (Obsoleted by {{IETF RFC|3410}})
* {{IETF RFC|2578}} (STD 58)&nbsp;— ''Structure of Management Information Version 2 (SMIv2)''
* {{IETF RFC|3410}} (Informational)&nbsp;— ''Introduction and Applicability Statements for Internet Standard Management Framework''
* [https://www.rfc-editor.org/info/std62 STD 62] contains the following RFCs:
** {{IETF RFC|3411}}&nbsp;— ''An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks''
** {{IETF RFC|3412}}&nbsp;— ''Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)''
** {{IETF RFC|3413}}&nbsp;— ''Simple Network Management Protocol (SNMP) Applications''
** {{IETF RFC|3414}}&nbsp;— ''User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)''
** {{IETF RFC|3415}}&nbsp;— ''View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)''
** {{IETF RFC|3416}}&nbsp;— ''Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)''
** {{IETF RFC|3417}}&nbsp;— ''Transport Mappings for the Simple Network Management Protocol (SNMP)''
** {{IETF RFC|3418}}&nbsp;— ''Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)''
* {{IETF RFC|3430}} (Experimental)&nbsp;— ''Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping''
* {{IETF RFC|3584}} (BCP 74)&nbsp;— ''Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework''
* {{IETF RFC|3826}} (Proposed)&nbsp;— ''The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model''
* {{IETF RFC|4789}} (Proposed)&nbsp;— ''Simple Network Management Protocol (SNMP) over IEEE 802 Networks''
* {{IETF RFC|5343}} (STD 78)&nbsp;— ''Simple Network Management Protocol (SNMP) Context EngineID Discovery''
* {{IETF RFC|5590}} (STD 78)&nbsp;— ''Transport Subsystem for the Simple Network Management Protocol (SNMP)''
* {{IETF RFC|5591}} (STD 78)&nbsp;— ''Transport Security Model for the Simple Network Management Protocol (SNMP)''
* {{IETF RFC|5592}} (Proposed)&nbsp;— ''Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)''
* {{IETF RFC|5608}} (Proposed)&nbsp;— '' Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models.''
* {{IETF RFC|6353}} (STD 78)&nbsp;— ''Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)''
* {{IETF RFC|7630}} (Proposed|Historic)&nbsp;— ''HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3''
* {{IETF RFC|7860}} (Proposed)&nbsp;— ''HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3''

== External links ==
{{Wikiversity | Simple Network Management Protocol}}

{{Authority control}}

[[Category:Application layer protocols]]
[[Category:Internet protocols]]
[[Category:Internet Standards]]
[[Category:Agent communications languages]]
[[Category:Network management]]
[[Category:System administration]]
[[Category:Management frameworks]]