Simple Network Management Protocol
Devices that typically support SNMP include cable modems, routers, network switches, servers, workstations, printers, and more.
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.
NMSs provide the bulk of the processing and memory resources required for network management.
The protocol also permits active management tasks, such as configuration changes, through remote modification of these variables.
MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OID).
MIBs use the notation defined by Structure of Management Information Version 2.0 (SMIv2, RFC 2578), a subset of ASN.1.
SNMPv3 also uses community strings, but allows for secure authentication and communication between SNMP manager and agent.
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: In 1990, these documents were superseded by: In 1991, RFC 1156 (MIB-1) was replaced by the more often used: SNMPv1 is widely used and is the de facto network management protocol in the Internet community.
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.
It introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request.
A 32-bit version 1 counter cannot store the maximum speed of a 10 gigabit or larger interface, expressed in bits per second.
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.
To overcome incompatibility, RFC 3584 defines two SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems.
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.
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.
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.
The IETF has designated SNMPv3 a full Internet standard,[23] the highest maturity level for an RFC.
[15] 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.
)[24] Some major equipment vendors tend to over-extend their proprietary command line interface (CLI) centric configuration and control systems.
[25][failed verification] In February 2002 the Carnegie Mellon Software Engineering Institute (CM-SEI) Computer Emergency Response Team Coordination Center (CERT-CC) issued an Advisory on SNMPv1,[26] after the Oulu University Secure Programming Group conducted a thorough analysis of SNMP message handling.
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.
If a higher level of security is needed the Data Encryption Standard (DES) can be optionally used in the cipher block chaining mode.
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] The security deficiencies of all SNMP versions can be mitigated by IPsec authentication and confidentiality mechanisms.
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.
