Management Architecture and Standards II

IACT 418 IACT 918Corporate Network Planning

Gene AwyzioSpring 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 functionsAs SNMP is simple it can handle many agentsSNMP 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

SNMP - the Management Protocol Used for TCP/IP

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 functionAll 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 managerSNMP 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 trapsOnce 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 authenticationSNMP 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 typesSNMP 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 1993SNMPv2 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 documentsWhen the work began on the 1996 documents, it was hoped that some minor tune-ups to the security portion would sufficeAs 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)

StandardsRFC Title

1901 Introduction to community-based SNMPv2

1902 Structure of management information for SNMPv2

1903 Textual conventions for SNMPv2

1904 Conformance statements for SNMPv2

1905 Protocol operations for SNMPv2

1906 Transport mappings for SNMPv2

1907 Management information base for SNMPv2

1908 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 oneFor 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 SNMPv1This involved two areas of the standards: management information protocol operations

protocol operations Two approaches are described in the

standard: use of proxy agents use of bilingual managers

For the proxy agent:

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:

For the bilingual manager:

This setup requires the manager to be able to handle both protocols and manager SNMPv1 and SNMPv2 agentsWhile 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.