SNMP (Simple Network Man­age­ment Protocol)

Devices of all kinds are combined in a network – from computers, servers, switches, or routers to printers, and so on. The higher the number of par­ti­cipants, the more effort and dif­fi­culties the ad­min­is­trat­or has in managing them. For this reason, the use of man­age­ment tools is vital if the func­tion­al­ity and security of all systems is to be guar­an­teed in the long run. One protocol used by many of these software solutions is the “Simple Network Man­age­ment Protocol” – or just SNMP, which is one of the most important standard protocols supported by almost all terminal devices today.

After two years of de­vel­op­ment, the first official version of SNMP was published in RFC 1157 in May 1990. The IETF (Internet En­gin­eer­ing Task Force) working group is re­spons­ible for the network protocol, which is part of the internet protocol family and is now also available in SNMPv2 and SNMPv3.The core function of the SNMP protocol is to enable central mon­it­or­ing and control of all com­pon­ents of a computer network. For this purpose, it describes the structure of the required com­mu­nic­a­tion packages and the com­mu­nic­a­tion flow between the central station and the in­di­vidu­al devices.

The con­nec­tion­less UDP protocol is used to transport the packages. The trans­por­ted data and in­form­a­tion is stored in a tree structure in the man­age­ment in­form­a­tion base (MIB).

Network man­age­ment via SNMP is based on an agent manager model. The central man­age­ment station is the system from which the ad­min­is­trat­or monitors and controls the various network par­ti­cipants. For this purpose, man­age­ment software is installed that enables SNMP data retrieval and the ini­ti­ation of certain actions. The agents, which are also ap­plic­a­tions, are the coun­ter­part on the side of the in­di­vidu­al network com­pon­ents. You enter the relevant data on the target host and pass it on to the man­age­ment station, but you can also make settings yourself and trigger certain actions. These kinds of agent ap­plic­a­tions are already in use by default in most popular Windows and Linux systems, for example in the form of the snmpd daemon (Linux only).

The SNMP protocol specifies seven possible message types for com­mu­nic­a­tion between manager and agent:

• GET request: GET requests are the default messages for re­triev­ing a specific record on the intended network device.
• GETNEXT request: This message format is required if sub­sequent data records need to be queried, e.g. for tables.
• GETBULK request: If a defined number of data records are to be retrieved with a single request, the manager ap­plic­a­tion can send a GETBULK request (from SNMPv2). Such a request is com­par­able to several suc­cess­ive GETNEXT requests.
• SET request: SET requests allow the manager to change one or more data records of the intended network device or to trigger certain actions. An example situation in which several ad­just­ments are necessary is con­fig­ur­ing an IP address, which also requires the spe­cific­a­tion of a network mask at the same time.
• GET response: If the manager has requested one or more data records or initiated changes or actions, the agent responds with GET responses. These response packages contain either the requested data, a con­firm­a­tion of the ad­just­ments, or an error message if the requests could not be answered correctly.
• SNMP trap: SNMP traps are agent messages sent without prompts from the manager station. This might happen if something un­ex­pec­ted occurs. The SNMP traps can com­mu­nic­ate the event in two ways. The first option is to add a unique iden­ti­fic­a­tion number, the meaning of which the manager can look up in the in­form­a­tion database (MIB). If option number two is selected, the SNMP traps not only inform about the event, but also contain the cor­res­pond­ing data without dis­play­ing a specific iden­ti­fic­a­tion number.
• INFORM request: INFORM requests basically fulfil the same function as SNMP traps. In contrast to these, however, the INFORM packages are char­ac­ter­ised by the fact that their receipt is ac­know­ledged by the manager. As a result, the agent can resend the message if it has not reached the manager in the first attempt.

As already mentioned, the Simple Network Man­age­ment Protocol pre­scribes the use of the con­nec­tion­less transport protocol UDP for the trans­mis­sion of the listed message packets. SNMP uses UDP port 161 for the various GET queries to the agents (including replies), while the auto­mat­ic­ally sent SNMP traps are sent via UDP port 162.

Ori­gin­ally, SNMP did not provide a way for managers to com­mu­nic­ate with each other, nor for agents to send messages that are ac­know­ledged. Also, the support of many ap­plic­a­tions only partially worked in the beginning, despite the approach as an open standard. Therefore, the protocol revisions of the following years were in par­tic­u­lar focused on in­teg­rat­ing cor­res­pond­ing mech­an­isms into the Simple Network Man­age­ment Protocol. Another important goal of the re­spons­ible IETF working group, which is reflected in par­tic­u­lar in the third protocol version, was to make the ad­min­is­tra­tion procedure more secure. These and other op­tim­isa­tion steps of the SNMP protocol are discussed in more detail in the following portraits of the in­di­vidu­al versions SNMPv1, SNMPv2, and SNMPv3.

SNMPv1 is the first version of the network man­age­ment protocol to provide the un­der­ly­ing manager-agent model, and is the basis for com­mu­nic­a­tion between the manager station and the in­di­vidu­al agents. The Simple Network Man­age­ment Protocol is described as a simple protocol that operates at the ap­plic­a­tion level and can be based on UDP (User Datagram Protocol) and Internet Protocol (IP), but also on com­par­able network protocols such as Ap­pleTalk's Datagram Delivery Protocol (DDP) or Internet Packet Exchange (IPX). The only built-in security mechanism is the exchange of a so-called community string, which is sent with the re­spect­ive requests.

A major problem with the first version of the SNMP protocol is that the security community string is only trans­mit­ted in plain text. For this reason, the de­velopers quickly worked on a new variant called secure SNMP, in which this string is trans­mit­ted in encrypted form. However, this version was never released because it was directly replaced by SNMPv2. Further im­prove­ments over the original protocol variant include optimised error handling, the pos­sib­il­ity of manager-to-manager com­mu­nic­a­tion, and more func­tion­al SET commands. However, the biggest advantage over SNMPv1 was the newly im­ple­men­ted message types GETBULK (for querying multiple data in a single request) and INFORM (for reply con­firm­a­tions to agent responses).

After the first, smaller step in the second protocol version, the IETF focused com­pletely on security in SNMPv3, and replaced the community string with a username and password. In addition, the third protocol execution contains functions to encrypt the trans­mis­sion of SNMP packets, unlike the pre­de­cessors. In total, SNMPv3 offers three different types of au­then­tic­a­tion and en­cryp­tion: