What is SNMPv1, SNMPv2 and SNMPv3? Types of SNMP PDU/Command/Message? Types of SNMP Traps?

SNMPv1

Only form of security used in SNMPv1 is community names. Community names are similar to passwords. The concept behind using community name is that all the managed devices in an SNMP network which are being managed by a network manager are considered to be in a community and a specific name i.e.community name can be assigned to it. While creating the SNMP PDU, this community name is set in the message header and any message received with the wrong value of the community name would be rejected by the receiver.
The community name set in the message header is in the form of plain text. the NMS issues a request, and managed devices return responses. Agents use the Trap operation to asynchronously inform the NMS of a significant event.

Disadvantage:

The biggest downsides are that it does not support 64 bit counters, only 32 bit counters, and that it has little security. A community string sent in plaintext

SNMP PDU’s:  Get Request, GetNext Request, Get Response, Set, Trap

SNMPv2

v2c is identical to version 1, except it adds support for 64 bit counters. It introduced the ability to transmit SMIv2 MIB-definitions of type “Counter64”. It calls for improved efficiency and performance by introducing the GETBULK operation. 2-New PDU’s introduced in SNMPv2 are Inform and Get Bulk.

Other advantages include:

• improved error handling
• improved SET commands

SNMP PDU’s:  Get Request, GetNext Request, GetBulk Request, Get Response, Set, Trap, Inform

SNMPv3

SNMPv3 provides the latest architecture for SNMP security. USM i.e. User Based Security Model and VACM i.e. View Based Access Control Model are part of SNMPv3. USM is based on the user’s access to a specific machine whereas VACM is based on user’s access to a view that contains specific MIB objects. Unless specified, default model in SNMPv3 is USM.

SNMP PDU’s:  Get Request, GetNext Request, GetBulk Request, Get Response, Set, Trap, Inform

The "EngineID" Identifier in SNMPv3 uniquely identifies each SNMP entity. Conflicts can occur if two SNMP entities have duplicate EngineIDs. The EngineID is used to generate the key for authenticated messages.

SNMPv3 provides the following security features:

• Authentication—Verifying that the request comes from a genuine source.

• Privacy—Encrypting data.

• Authorization—Verifying that the user allows the requested operation.

• Access control—Verifying that the user has access to the objects that are requested.

noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).

User Authentication:  Verification of the identity of the SNMP Entity (Manager or Agent) sending the request. Managers and Agents share knowledge of valid users, and there is a shared secret key defined for each user. When an Entity sends an SNMPv3 message, the secret key is used to create a hash of the message, and this hashed value is included with the message. If the receiving Entity can recreate this hash, then the message is said to be “authenticated” as from a valid user.

Encryption:  Message payload can be optionally encrypted based on a second shared key.

VACM (View Access Control Model):  Agents can now be configured to control who can access which MIB Objects under agent management.  For example, User = “Operations Supervisor” can access critical read-write control data, while User = “Plant Monitor” can access only read-only status data. Message Timeless Checks ensure that messages are not delayed or replayed.

Authorization Protocals: MD5, SHA1.

Encription protocal: DES, AES128/192/256

SNMP PDU/Command/Message Types

SNMP Message	From / To		Message Description
Get Request	Manager / agent	Accesses and retrieves the current value of one or more MIB objects on an SNMP agent .
GetResponse	Agent / manager	Replies to a Get, GetNext, or Set operation.
GetNext Request	Manager / agent	Browses the entire tree of MIB objects, reading the values of variables in the MIB sequentially. Typically, you use GetNext to obtain information from selected columns from one or more rows of a table. GetNext is especially useful for browsing dynamic tables, such as an internal IP route table or an ARP table, reading through the table one row at a time.
GetBulk Request	Manager / agent	Retrieves data in units as large as possible within the given constraints on the message size. GetBulk, which accesses multiple values at one time without using a GetNext message, minimizes the number of protocol exchanges required to retrieve a large amount of information. The number of consecutive variables fetched, will depend on the value specified in the Max-Repetitions box. By default it is set to 50. To avoid fragmentation, restrict the maximum message size to a size smaller than the path maximum transmission unit (MTU), the largest frame size allowed for a single frame on your network. Typically, when it is not known how many rows are in a table, GetBulk is used (rather than GetNext) to browse all rows in the table.
Set Request	Manager / agent	Changes the current value of a MIB object. In order to update a MIB value on the SNMP agent, the SNMP manager must have write access to the object. Set is used infrequently, because most MIB objects are read-only by default, so that unauthorized changes cannot be made.
Trap	Agent / manager	Notifies the specified SNMP manager (the trap destination) when an unexpected event occurs locally on the managed host. You can use traps for limited security checking (such as notifying the trap destination if the agent receives an information request from an SNMP manager that it does not recognize) or for troubleshooting (such as notifying the trap destination if the WINS service fails).
Inform	Agent / manager & in response Manager/Agent	Unlike Trap, its get the acknowledgement from the manager. If manager did not send acknowledgment. It re-sends.

SNMP Trap Types

Trap Type	Trap Name	Description
0	ColdStart	The SNMP agent initialized its configuration tables.
1	WarmStart	The SNMP agent re-initialized its configuration tables.
2	LinkDown	The state of a network adapter on the SNMP agent changed from up to down.
3	Linkup	The state of a network adapter on the SNMP agent changed from down to up.
4	authenticationFailure	The SNMP agent received a message from an SNMP manager, but the message contained an invalid community name.
5	egpNeighborLoss	The SNMP agent could not communicate with its Exterior Gateway Protocol (EGP) peer.
6	enterpriseSpecific	Reserved for vendor-defined error conditions and error codes.