CSE 588: Compare and Contrast Paper #1 Comparing SNMPv2 with SNMPv1 Executive Summary ================= SNMP (Simple Network Management Protocol) v1 was designed in the mid to late 1980s as a short term solution to allow the management of TCP/IP-based internets. In the long-term, the use of the OSI network management framework was to be examined. However, SNMPv1 became the network management protocol of choice as no better choice became available. In the early 1990s work began to define SNMPv2 which would extend the capabilities of v1, and fix some of its deficiencies. However as the protocol became less simple (initial specifications for SNMPv2 were 400+ pages compared to the 36 pages for SNMPv1) progress slowed and some industry members complained about the complexity. A rewritten set of RFCs was published in late 1995. Most notably this extended the protocol to solve some of the performance deficiencies of SNMPv1. However the working group failed to reach agreement on the key areas of security and administrative framework. As a result SNMPv2 has not been accepted by the industry as a de facto standard in the way that SNMPv1 was and work continues to define a new standard. This report gives an introduction to the capabilities of SNMPv1. It then lists the major issues that SNMPv2 was supposed to address, and describes the areas where agreement was reached. Finally it briefly summarizes the differences between the two main v2 security factions. Background ========== What is Network Management ISO defined five key areas of network management: * Fault Management For example detecting that a particular communications link has failed. * Configuration Management For example viewing and manipulating the address translation tables in a host or the routing information in a router. * Performance Management For example measuring the load on a particular device to determine if network capacity is sufficient. * Security Management For example controlling who can make changes to the network system or view configuration information. * Accounting Management For example gathering information on how much traffic was generated and from where. Introduction to SNMPv1 SNMPv1 was defined by RFC 1157 which reached full standard status in May 1990. Unlike many other protocols that include "Simple" in their name SNMPv1 really was quite simple. This has been a major factor in its widespread acceptance. SNMP models all management operations as alterations or inspections of variables. A manager interacts with an SNMP agent on a remote host. The manager can retrieve (get) or alter (set) variables. SNMP does not define any imperative commands. For example there is no command to reboot a workstation. However this could be accomplished by simply setting a variable indicating the number of seconds until system reboot. This architecture kept the protocol simple by moving much of the complexity into the definition of what variables exist and how they can be manipulated. In SNMP terminology this is defined by a MIB (Management Information Base). There is a mandatory MIB that all devices must support. Additional MIBs are defined that are specific to particular device types, or for particular protocols. These MIBs can be further extended (subclassed in object oriented terminology) by individual manufacturers to provide additional information that is specific to their devices. If a new type of device (say an ATM switch) becomes widely deployed then a new MIB can be defined for devices of this type without requiring any changes to the SNMP protocol itself. Indeed there are many more RFCs defining MIBs than there are defining aspects of the protocol itself. MIB items are defined and encoded for wire transmission using a subset of the ASN.1 (Abstract Syntax Notation One) encoding scheme. SNMPv1 Protocol Commands SNMP transfers information between a manager and an agent by exchanging messages over an unreliable datagram transport service. The preferred transport is the Internet User Datagram protocol (UDP). Each message contains a Protocol Data Unit (PDU) that defines the operation to be performed. SNMPv1 defines five different PDUs: GetRequest This PDU is used to get the values of a list of variables from a particular host. GetNextRequest This PDU is used to get the next value for multi-valued data items (for example the entries in a routing table). The manager specifies one or more variables with values, and the agent returns the next value(s) (in sorted order) for each of the requested variables. SetRequest This PDU is used to set the values of a list of variables for a particular host. GetResponse This PDU is returned by an Agent in response to the three preceding PDUs. It contains the requested (or set) data items along with a result code. Trap This PDU is quite different to the other four. It is generated by an Agent in response to particular important events. A small number of events such as coldStart, warmStart, linkDown, and linkUp are defined. A particular Trap PDU is generated by an agent only at the request of an SNMP manager application. However the means by which this and the destination address of the trap message are configured is "implementation-specific". Key Issues ========== The main weaknesses of SNMPv1 which SNMPv2 was supposed to address are: Expressiveness of MIB definitions As the devices and protocols to be monitored became more complex the MIBs to describe them needed greater expressiveness. Performance When SNMP is deployed over WANs traffic overhead may be excessive. There are two main reasons for this. Firstly, many key data structures in typical MIBs are expressed as multi-valued data items. For example the entries in a routing table. In SNMPv1 these items can be retrieved only by sending repeated GetNextRequest messages where each message retrieves a single additional table item. Secondly, SNMPv1 only has the concepts of simple agents and managers. Consider a scenario in which multiple hosts on the other side of a WAN link are to be monitored. With SNMPv1 the manager must send a separate message across the WAN link for each host. This generates excessive traffic, and also isn't very scaleable. Security Without question, network and systems management data is one of the most sensitive of all information types. Unauthorized persons with access to management data can not only discover an organization's network topology and computer asset placement, but also alter critical system parameters and bring a mission critical network to its knees. SNMPv1 is still primarily used only for monitoring due to the protocol's lack of well defined security mechanisms. The SNMPv1 specification considered the security issue, and said that agents and managers should be grouped into Communities. An agent would identify a message as authentic by verifying that it was sent by a manager in the same community as itself. It also introduced the concepts of views and access modes onto a MIB. However it did not specify how such schemes were to be implemented. As a result the security support varied from product to product, and inter-operability was not guaranteed. In fact there are several different dimensions to security: * Authentication Verifies the identity of a message's origin and the integrity of the data in the message. * Privacy Management data should be encrypted to protect it from somebody eavesdropping with a protocol analyzer. * Authorization Verifies that the originator of the message is authorized to get or set the requested MIB variables. Analysis Status of v2 standardization process Initial RFCs were published in April 1993 and were granted Proposed Standard status by the IETF. However they were not accepted as a de facto standard by the industry. There were complaints about the complexity of the design of the security and administrative framework. The working group was rechartered in late 1994 to develop SNMPv2 further. However the working group failed to reach agreement on the key areas of security and administrative framework. As a result the working group decided to publish all the specifications on which they had reached consensus, whilst work continued on the specifications related to the security and administrative aspects. Eight SNMPv2 RFCs (1901-1908) on which the working group had reached consensus were published in December 1995 and were given Draft Standard status by the IETF. The next two sections describe how these addressed the non security issues listed above. Then the final section describes the current status of the security issue. Expressiveness of MIB definitions The expressiveness of MIB definitions was enhanced by supporting a larger subset of ASN.1. Also new types were defined that could be used when constructing MIBs. For example a 64 bit counter type was defined for instrumenting rapidly increasing variables such as byte counters in high speed networks. Performance The two performance problems identified above were addressed by defining new SMTP PDUs. There were also some minor changes to the existing v1 PDUs which are described first. SNMPv2 retains the GetRequest, GetNextRequest, and SetRequest PDUs. Their behavior has been specified more exactly (for example new error codes were defined), however these operations remain essentially unchanged from v1. The SNMPv1 PDU GetResponse has been replaced by one called Response. This is effectively just a rename. The v1 GetResponse name was inappropriate as this PDU was also used as the response to a SetRequest. A PDU called SNMPv2-Trap replaces the previous Trap PDU. Again there are no major changes here. The specification still says that the destination(s) to which a SNMPv2-Trap PDU is sent is determined in an implementation-dependent fashion. GetBulkRequest The first new PDU is GetBulkRequest. One of the aims of this PDU is to minimize the number of protocol exchanges required to retrieve a large amount of management information. In particular this addresses the weakness in v1 where tables could be read only one value at a time using the GetNextRequest PDU. The GetBulkRequest PDU allows the caller to specify two additional parameters - non-repeaters and max-repetitions. The Non-repeaters parameter allows the caller to request both single and multi-valued variables in the same message by identifying the range of variables which are single valued (i.e. non repeating). For multi-valued variables the max-repetitions parameter allows the caller to specify the number of values to be returned by the call. The GetBulkRequest PDU also allows a SNMPv2 manager to request that the response be as large as possible given the constraints on message sizes. These constraints include the limits on the size of messages which the agent can generate, and the manager can receive. InformRequest The second new PDU, InformRequest, is designed to solve the scalability problem of SNMPv1's centralized management scheme by allowing more distributed hierarchical management systems to be implemented. The InformRequest introduces a new pattern of communication. SNMPv1 supported two patterns of communication: * Manager to Agent (i.e. GetRequest, GetNextRequest, SetRequest) * Agent to Manager (i.e. Trap) The InformRequest is a Manager to Manager communication, where one manager sends information from a MIB view to another manager. For example this allows a single master manager to receive information from a number of second tier managers. These managers act as remote collection stations. They localize the polling so that the master manager doesn't need to send multiple requests to a collection of hosts on the other side of a WAN. Instead a manager that is local to those hosts can gather information and then forward that to the master manager using an InformRequest PDU. The receiving manager responds to the InformRequest with a Response PDU. Report The last new v2 PDU does not help performance. In fact the usage and precise semantics of the Report PDU are not presently defined in the v2 specifications. An SNMP administrative framework making use of this PDU must define its usage and semantics. Security As noted above in the Status of v2 standardization process section the SNMPv2 working group did not reach agreement on a security and administrative framework. The RFCs published (1901-1908) still rely on the older and weaker "Community" based concept of security. Hence these RFCs are often collectively referred to as SNMPv2c. The discussion in the Working Group became polarized around two sets of security/administrative framework specifications. A full comparison of the features and differences between these is beyond the scope of this report. However the two major factions are described briefly in the following sections. SNMPv2U This is also known as USEC (for User based security). It is defined in RFC 1909-1910. These specifications took a minimalistic approach, and focused on the needs of simple, small agents. SNMPv2u is supported by representatives from Cisco Systems and Bell Northern Research (amongst others). SNMPv2* The "*" indicates that these specifications were a synthesis of multiple proposals. In fact SNMPv2* is 80% based on the USEC proposal, but in the opinion of its creators is more complete and correct, incorporating features addressing the needs of management console implementers and application writers. It also defines a remote configuration MIB. SNMPv2* is supported by representatives from Cabletron, Hewlett Packard, and SNMP Research (amongst others). Conclusions =========== The portions of SNMPv2 on which the working group reached consensus do directly tackle the major issues in SNMPv1. As a result adoption of these technologies is proceeding. However the failure of the working group to agree on a security model have slowed the overall acceptance of SNMPv2 and produced negative publicity. The two groups realize this and the technical distance between the two groups is shrinking, however differences on some key technical points are still firmly held. Each requires more work if they are to become a solution which will last as long as v1 has and achieve v1's level of success. Some participants are suggesting that the SNMPv2 name should be abandoned because of the negative baggage associated with it. A request forwarded to the IETF recommends development of SNMPng (for next generation) or SNMPv3 based on the best aspects of SNMPv2U and SNMPv2*. References ========== Network Management Appendix, Computer Networks - A Systems Approach, Peterson and Davie SNMP and CMIP: An Introduction to Network Management http://www.inforamp.net/~kjvallil/t/snmp.html SNMP FAQ http://www.cis.ohio-state.edu/hypertext/faq/usenet/snmp-faq/part1/faq.ht ml http://www.cis.ohio-state.edu/hypertext/faq/usenet/snmp-faq/part2/faq.ht ml SNMPv1: RFCs RFC 1155 Structure and Identification of Management Information for TCP/IP-based internets RFC 1157 A Simple Network Management Protocol RFC 1212 Concise MIB Definitions SNMPv2: History http://www.snmp.com/pressrel/v2-background.html SNMPv2: RFCs RFC 1901 Introduction to Community-based SNMPv2 RFC 1902 SMI for SNMPv2 RFC 1903 Textual conventions for SNMPv2 RFC 1904 Conformance statements for SNMPv2 RFC 1905 Protocol operations for SNMPv2 RFC 1906 Transport mappings for SNMPv2 RFC 1907 MIB for SNMPv2 RFC 1908 Coexistence between SNMPv1 and SNMPv2 SNMPv2: Current Status and Future Outlook http://www.snmp.com/white.html SNMPv2* http://www.snmp.com/v2star.html