Editing Simple Network Management Protocol (section)

== 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 different header and 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 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"/>