Management Architecture and Standards II IACT 418 IACT 918 Corporate Network Planning Gene Awyzio Spring 2001

SNMP - the Management Protocol Used for TCP/IP SNMP includes the following key capabilities: Get Set Trap The standards do not specify The number of management stations The ratio of management stations to agents

SNMP - the Management Protocol Used for TCP/IP In general, it is prudent to have at least two systems capable of performing the management station functions As SNMP is simple it can handle many agents SNMP is designed to be an application-level protocol that is part of the TCP/IP protocol suite which operates over the user datagram protocol (UDP)

SNMP - the Management Protocol Used for TCP/IP

From a management station, three types of SNMP messages are issued on behalf of a management application: GetRequest GetNextRequest SetRequest

SNMP - the Management Protocol Used for TCP/IP The first two are two variations of the get function All three messages are acknowledged by the agent in the form of a GetResponse message, which is passed up to the management application

SNMP - the Management Protocol Used for TCP/IP An agent may issue a trap message in response to an event that affects the MIB and the underlying managed resources - this is received by the manager SNMP relies on UDP, which is connectionless so SNMP is itself connectionless ie each exchange is a separate transaction between a management station and an agent

Trap - Directed Polling Preferred strategy is: A management station can poll all of the agents it knows for some key information Once the baseline is established, the management station refrains from polling Each agent is responsible for notifying the management station of any unusual event

Trap - Directed Polling These events are communicated in SNMP messages known as traps Once a management station is alerted to an exception condition, it chooses to take the appropriate action

Trap - Directed Polling Trap-directed polling can result in substantial savings of Network capacity Agent processing time Reduces unnecessary polling of agents by managers thus reducing management induced network traffic

Limitations of SNMP SNMP may not be suitable for the management of very large networks Each agent needs to be polled and generates trap traffic SNMP is not suited to retrieving large volumes of data such as a entire routing table SNMP traps are unacknowledged meaning the agent generating the trap does not know if the manager received it

Limitations of SNMP Basic SNMP standard only provides trivial authentication SNMP does not directly support imperative commands with parameters, conditions, status and results

Limitations of SNMP SNMP MIB model is limited not supporting sophisticated management queries based on object values or types SNMP does not support manager to manager communications ie no mechanism for one manager to find out about another network managers, managed network elements

SNMPv2 :1991/1992 Networks grow larger and larger SNMPv1 became more and more inadequate OSI implementations and standardization were still not ready Network managers recognised this, so the call went out for an extension to SNMP in the mean time till OSI’s CMIP became available

SNMPv2 :1991/1992 One major flaw SNMPv1 did not have any security facilities For this reason SNMPv1 network human managers often disabled the ‘set’ PDU crippling the network management facility

Adding Security To address this problem a set of RFC’s called ‘secure SNMP’ was issued as proposed in July 1992 secure SNMP did not address other deficiencies related to performance and functionality of SNMPv1 SMP was also issued in July 1992 as a set of 8 documents, they were not RFC’s They constituted a private proposal to the internet community to upgrade SNMPv1

SMP The proposed extensions defined in SMP fell into three categories Scope Size, speed, and efficiency Security and privacy

SMP and Secure SNMP The ‘Internet community’ came to the consensus that there should be a second generation SNMP that would include both security and functional enhancements enable users and vendors to make a smooth transition from SNMPv1 to what becomes known as SNMPv2

Adding Security Two working groups were formed: one for security aspects one for all other aspects such as protocol and management information Work began in October 1992 to be completed March 1993, but was completed by end of 1992

Adding Security The work of the two groups was combined and published as proposed internet standards in March 1993 SNMPv2 was revised in 1996 by an IETF task Force New RFC’s contained no security! The rest of the standard experienced minor changes

Community The standard SNMPv2 makes use of the SNMPv1 message wrapper, with its use of the community concept This “administrative framework” for SNMPv2 is termed “community based snmpv2” or SNMPv2c

Community In SNMPv1 an SNMP community is a relationship between A SNMP agent A set of SNMP managers That defines authentication, access control, and proxy characteristics

Community In SNMPv1 Communities are defined locally within the agent  Each community is given a unique (within the agent) community name The management station must keep track of and store all the community names of each of its managed agents  The management stations within the community are provided with and must use this community name in all set and get operations with this agent There is no reason why the same name may not be used by different agents - as the agent uses this name locally

Community The SNMPv2 message is wrapped with a PDU in a SNMPv1 format including a version number A community name

What Happened to the Security? Little enthusiasm among vendors and users for the way in which security was specified in the 1993 documents When the work began on the 1996 documents, it was hoped that some minor tune-ups to the security portion would suffice As the effort was nearing completion it was shown that the security portion of snmpv2 was fatally flawed!

What Happened to the Security? To make a long story short, there was an extension of the deadline for completing the new snmpv2 documents to allow time for a new consensus to develop on a new security specification Deadlock occurred No consensus reached Time ran out Then the plug was pulled on the process and the new snmpv2 was issued without security enhancements

What Happened to the Security? This decision had the advantage of solidifying the specification of the many functional enhancements found in snmpv2, but leads onto the need for another version of SNMP (version 3)

Standards RFCTitle 1901 Introduction to community-based SNMPv Structure of management information for SNMPv Textual conventions for SNMPv Conformance statements for SNMPv Protocol operations for SNMPv Transport mappings for SNMPv Management information base for SNMPv Coexistence between version 1 and version 2 of the internet-standard network management framework

SNMPv2 Enhancements An overall change implemented in SNMPv2 is that it can support either a highly centralized network management strategy or a distributed one For distributed some systems can operate as both a manager and a agent

SNMPv2 Enhancements For a system acting in dual modes of agent and manager it: accepts commands from a superior management system it can also issue trap messages to the superior manager

SNMPv2 Enhancements The key enhancements to SNMP that are provided in SNMPv2 fall into the following categories: Structure of management information (SMI) Manager-to-manager capability Protocol operations

SNMPv2 Protocol operations enhancements (over SNMPv1) The most noticeable change in protocol operations is the inclusion of two new PDUs: GetBulkRequest PDU : enables the manager to retrieve large blocks of data efficiently --- it is well suited to retrieving multiple rows in a table eg routing table. InformRequest PDU : enables one manager to send trap type of information to another manager.

SNMPv1 and SNMPv2 coexistence SNMPv2 was designed to co-exist with SNMPv1 This involved two areas of the standards: management information protocol operations Two approaches are described in the standard:  use of proxy agents  use of bilingual managers

For the proxy agent:

The main point here is that GetBulkRequest is converted to a GetNextRequest with only the first “row” of the table or variables being accessible (but the device is SNMPv1 enabled so its expecting that this is the norm)

For the bilingual manager:

This setup requires the manager to be able to handle both protocols and manager SNMPv1 and SNMPv2 agents While SNMPv2 provided enhancements in functionality, especially in the manager to manager functions, the lack of security still inhibits the secure use of SNMP on managed networks.