Simple Network Management Protocol

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:

• 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

In 1990, these documents were superseded 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

In 1991, 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

SNMPv1 is widely used and is the de facto network management protocol in the Internet community.[12]

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.[13] 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."[14] 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.

SNMPv2, defined by RFC 1441 and 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.[13] This version of SNMP reached the Proposed Standard level of maturity, but was deemed obsolete by later versions.[15]

Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined in RFC 1901–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.[15] It was later restated as part of SNMPv3.[16]

User-Based Simple Network Management Protocol version 2, or SNMPv2u, is defined in RFC 1909–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.[17]

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 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.

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, RFC 3584 defines two SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems.

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 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. Additionally, the proxy agent receives and maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

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.

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.[1] The most visible change was to define a secure version of SNMP, by adding security and remote configuration enhancements to SNMP.[18] 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 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[19] 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.[1] Each SNMPv3 message contains security parameters which are encoded as an octet string. The meaning of these security parameters depends on the security model being used.[20] The security approach in v3 targets:[21]

• 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 RFC 3411–RFC 3418[22] (also known as STD0062) as the current standard version of SNMP. The IETF has designated SNMPv3 a full Internet standard,[23] the highest maturity level for an RFC. It considers earlier versions to be obsolete (designating them variously Historic or Obsolete).[15]

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.[27]^: 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.[28]

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, 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.[27]^: 54

SNMP is available in different versions, each 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 attacks. 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.[27]^: 52

SNMPv3 may be subject to brute force and dictionary attacks 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).[29] 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.

The security deficiencies of all SNMP versions can be mitigated by IPsec authentication and confidentiality mechanisms. SNMP also may be carried securely over Datagram Transport Layer Security (DTLS).[10]

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.[10] 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.[27]^: 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.[8]^: 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.[30] System and network administrators frequently do not change these configurations.[8]^: 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.