1

2
3
1. Implications:
An RMON probe can monitor traffic on the basis of network-layer
protocols and addresses, including the Internet Protocol (IP). This
enables the probe to look beyond the LAN segments to which it is
attached and to see traffic coming onto the LAN via routers.
Because an RMON probe can decode and monitor application-level
traffic, such as e-mail, file transfer, and Word Wide Web protocols,
the probe can record traffic to and from hosts for particular
applications.
4
1. RMON1 probe can provide detailed information about the MAC-level
traffic to and from each host on each attached LAN.
2. If a router is attached to one of these LANs, the RMON1 probe can only
monitor the total traffic into and out of that router; it has no way of
determining the ultimate source of incoming traffic arriving via the router
or the ultimate destination of outgoing traffic leaving via the router.
3. RMON2 probe can see above the MAC layer by reading the header of the
enclosed network-layer protocol, which is typically IP. This enables the
probe to analyze traffic passing through the router to determine the
ultimate source and destination.
4. With RMON2, a network management application can be implemented
that will generate charts and graphs depicting traffic percentage by
protocols or by applications. Such a level of detail is useful in controlling
load and maintaining performance.
5. In RMON2 terms, any protocol above the network layer is considered
"application level".
5
1. protocolDir: a master directory of all of the protocols that the probe
can interpret.
2. protocolDist: aggregate statistics on the amount of traffic generated
by each protocol, per LAN segment.
3. nlHost: statistics on the amount of traffic into and out of hosts on the
basis of the network-layer address.
4. nlMatrix: statistics on the amount of traffic between pairs of hosts on
the basis of network-layer address.
5. alHost: statistics on the amount of traffic into and out of hsots on the
basis of application-level address.
6. alMatrix: statistics on the amount of traffic between pairs of hosts on
the basis of application-level address.
7. usrHistory: periodically samples user-specified variables and logs that
data based on user-defined parameters.
8. probeConfig: defines standard configuration parameters for RMON
probes.
6
7
1. protocolDir group addresses a key difficulty in the remote monitoring
of protocol traffic above the MAC layer. It provides a single central point
for storing information about types of protocols.
2. The protocol directory group provides a way for an RMON2 manager to
learn which protocols a particular RMON2 probe interprets. This
information is especially important when the manager and probe are from
different vendors. (Figure 10.5 RMON2 protocol directory Group).
3. The group includes a protocol directory table, with one entry for each
protocol for which the probe can decode and count protocol data units
(PDUs). The table covers MAC-, network-, and higher-layer protocols, The
group also includes protocol DirLastChange, which contains the time
of the last table update.
4. The first two columnar objects in protocolDirTable, which are
protocolDirID and protocolDirParameters, are used as
indexes that uniquely identify a single row and therefore uniquely identify
one supported protocol.
5. The protocolDirID object contains a unique octet string for a specific
protocol, which are arranged in a tree-structured hierarchy, similar to that
of MIB objects. The root of the tree is the identifier of a MAC-level
protocol.

8
1. Each of the bits in the parameter octet is encoded separately to define a
particular capability. The two least significant bits have reserved values
that apply to all protocols:
countsFragments (bit 0): Higher-layer protocols encapsulated
within this protocol will be counted correctly even if this protocol
fragments the upper-layer PDUs into multiple fragments.
tracksSessions (bit 1): correctly attributes all packets of a
port-mapped protocol; that is, a protocol that starts sessions on a
well-known port or socket and then transfers them to dynamically
assigned ports or sockets for the duration of the session, i.e. TFTP.
2. A new protocol descriptor macro has been specified by using a simple
Backus-Naur Form (BNF) syntax rather than ASN.1.
Protocol-identifier :==
<protocol-name> "PROTOCOL - IDENTFIER"
"PARAMETERS" "{"<param-bit-list>"}"
"ATTRIBUTES" "{"<attrib-bit-list>"}"
"DESCRIPTION" """<protocol-description>"""
["CHILDREN" """<children-description>""" ]
["ADDRESS-FORMAT" """<address-format-description>""" ]
["DECODING" """<decoding-description>""" ]
["REFERENCE" """<reference-description>""" ]
"::=" "{"<protocol-encoding-identifiers>"}"
9
1. The remainder of the objects provide enumerated values that further define
the protocol entry (TABLE 10.1):
protocolDirType: may be defined as extensible(0) if the agent
or manager may extend this table by creating entries that are
children of this protocol; and as
addressRecorgnitionCapable(1), which indicates that the
probe can not only count packets for this protocol but can also
recognize source and destination address fields for finger-grained
counting.
protocolDirAddressMapConfig: set to
notSupported(1) if not capable of performing address mapping;
if capable, then the value may be set to supportedOff(2) or
supportedOn(3).
protocolDirHostConfig: may be set to
notSupported(1), supportedOff(2), or supportedOn(3)
with respect to the network-layer and application-layer host table
for this protocol.
protocolDirMatrixConfig: may be set to
notSupported(1), supportedOff(2), or supportedOn(3)
with respect to the network-layer and application-layer matrix
tables for this protocol.
9
10
1. Each row in protocolDistControlTable refers to a unique
network interface for this probe and controls a number of rows of
protocolDistStatsTable, one for each protocol recognized on that
interface.
2. The protocolDistControlTable includes the following columnar
objects:
protocolDistControlIndex: an integer that uniquely identifies a row in
the protocolDistControlTable (The same integer is also used to index
corresponding rows in protocolDistStatsTable.)
protocolDistControlDataSource: identifies the interface -- and hence
the sub-network -- that is the source of the data for this row.
protocolDistControlDropedFrames: total number of received frames
for this interface that the probe chose not to count (Typically, a frame is not
counted when the probe is out of some resources and decides to shed load from
this collection.)
protocolDistControlCreateTime: the value of sysUpTime when this
control entry was activated.
3. The protocolDistStatsTable includes one row for each protocol
in protocolDirTable for which at least one packet has been seen.
4. The protocolDistStatsTable includes the following objects:
protocolDistStatsPkts: the number of packets received for this protocol.
protocolDistStatsOctets: the number of octets transmitted to this
address since it was added to the nlHostTable.
11
1. addressMapInserts: the number of times an address-mapping entry has been
inserted into the data table.
2. addressMapDeletes: the number of times an address-mapping entry has been deleted
from the data table.
3. addressMapMaxDesiredEntries: the desired maximum number of entries in
addressMapTable (If this value is set to -1, the probe may create any number of
entries in addressMapTable.).
4. The addressMapControlTable includes the following columnar objects:
addressMapControlIndex: an integer that uniquely identifies a row in the
addressMapControlTable
addressMapControlDatasource: identifies the interface, and hence the
subnetwork, that is the source of the data for this row and that this row is configured to
analyze.
addressMapControlDroppedFrames: total number of received frames for this
interface that the probe chose not to count (Typically, a frame is not counted when the
probe is out of some resources and decides to shed load from this collection.)
5. The addressMapTable includes the following objects:
addressMapTimeMark: a time filter for this entry
addressMapNetworkAddress: the network address for this entry
addressMapSource: the last interface or repeater port on which the associated
network address was seen.
addressMapPhysicalAddress: the last source MAC address on which the
associated network address was seen.
addressMapLastChange: the value of sysUpTime at the time this entry was
updated.
6. This group can be used to detect duplicated IP address.
12
1. nlHost group consists of a control table, nlHostControlTable, and
a data table, nlHostTable.
2. There is no one-to-one relationship between entries in nlHostTable and
alHostTable as there may be multiple application-level protocols
active at the same network-layer host (for example, multiple applications
running over IP on the same host).
3. The nlHostTable will create entries for all network-layer protocols in
the protocol directory table whose value of
protocdolDirNlHostConfig is equal to supportedOn(3). The
probe adds entries to this table for all addresses seen as the source or
destination address in all packets with no MAC errors.
4. The purpose of nlHostTable is to collect basic statistics on traffic into
and out of each discovered hosts, broken down by network-layer address.
5. The alHostTable will create entries for all application-level protocols
in the protocol directory table whose value of
protocolDirAlHostConfig is equal to supportedOn(3). The
probe adds entries to this table for all addresses seen as the source or
destination address in all packets with no MAC errors.
6. The alHostTable enables a user to trace the traffic into and out of a a
host on the basis of application protocol.
13
1. The network-layer matrix group consists of five tables:
Two control tables and three data tables.
One control table with its two associated data tables deal with the collection of
matrix statistics (FIGURE 10.12), while the other control table and its associated
data table deal with the collection of topN statistics (FIGURE 10.13).
2. The nlMatrixSDTable is used to store statistics on traffic from a
particular source network-layer address to a number of destinations. The
nlMatrixSDTable will create entries for all network-layer protocols in
the protocol directory table whose value of
protocolDirNlMatrixConfig is equal to supportedOn(3).
3. The nlMatrixSDTable is indexed first by the row of
nlMatrixControlTable that controls it; then by a time filter; then by
the network-layer protocol; then by the network-layer source address; and
then by the network-layer destination address.
4. The nlMatrixDSTable contains the same information as
nlMatrixSDTable but is indexed by the destination address before the
source address.
5. In RMON2 TopN statistics table, the ranking is of the traffic between pairs
of hosts based on some parameters.
6. RMON2 TopN tables automatically retrigger when the sorted completes.
The sorted report is updated every TopNDuration seconds
automatically.
13
14
1. The application-layer matrix group consists of three data tables and one
control table. Two of the data table deal with the collection of matrix
statistics, while the other data table deals with the collection of topN
statistics.
2. The two data tables that deal with application-level source/destination
statistics are controlled by nlMatrixControlTable.
3. The alMatrixSDTable is used to store statistics on traffic from a
particular source application-layer address to a number of destinations. The
alMatrixSDTable will create entries for all application-layer protocols
in the protocol directory table whose value of
protocolDirAlMatrixConfig is equal to supportedOn(3).
4. The alMatrixDSTable contains the same information as
alMatrixSDTable but is indexed by destination address before source
address.
5. The application-layer TopN statistics control table and data table have
almost exactly the same structure and functionality as the network-layer
TopN statistics control and data tables.
15
1. usrHistory group consists of a three-level hierarchy of tables (Figure
10.15).
usrHistoryControlTable: specifies the details of the
sampling function.
usrHistoryObjectTable: specifies the variables to be
sampled.
usrHistoryTable: records of the specified data.
2. Figure 10.16 illustrates the relationship between the two control tables and
the data table.
16
1. A control string is used to communicate with a modem or serial data
switch and contains embeded commands to control how the device will
interact with the remote device through the serial interface.
2. The serial configuration table contains one row for each serial interface on
the probe.
3. The network configuration table contains one row for each network
interface on the probe.
4. The trap destination table defines the destination addresses for traps
generated from this device. The table maps a community to one or more
trap destination entries.
5. The serial connection table stores the parameters needed for initiating a
SLIP (Serial Line Interface Protocol) connection to a management station.
17
1. filterProtocolDirLocalIndex:
If this object has a nonzero value, its value indicates a protocol
defined in protocolDirTable.
All packets that do not match this protocol and any associated
filters are discarded.
For packets that do match this protocol, the headers of all lower-
level protocol are stripped off and the regular filter algorithm is
performed on the remainder.
For example, if the protocol specified is IP, then the filter removes
the MAC-level header and trailer from all incoming IP packets and
then performs the filtering operation on the IP packet.
18
19
20
21
1.SNMPv2 expands the functionality of SNMP and broadens its applicability
to include OSI-based as well as TCP/IP-based networks.
2.This chapter will introduce SNMPv2 standard and then examine the
management information aspects of the standard, then protocol itself and
finally discuss the additional MIB-related aspects of SNMP2.
22
1. SNMP had two advantages:
SNMP, its associated structure of management information (SMI), and its
management information base (MIB) are quite simple and therefore can be easily
and quickly implemented.
SNMP is based on the Simple Gateway Monitoring Protocol (SGMP), for which
a great deal of operational experience had been gained.
2. A two track policy was adopted: SNMP would be used to meet immediate
network management needs, and an OSI-based solution would be pursued
for long-term needs. The OSI-based solution was CMOT (CMIP over
TCP/IP), which essentially enabled OSI system management protocols to
operate on top of TCP.
However this two-track strategy has not worked out because:
The complex object-oriented approach of OSI was incompatible with
quick deployment of SNMP.
The development of stable OSI standards for network management, and
the subsequent availability of product implementation, has taken much
longer than anticipated.
3. The extensions defined in the SMP proposal fall into four categories:
Scope
Size, speed and efficiency
Security and privacy
Deployment and compatibility
23
1. The SNMPv2 SMI expands the SNMP SMI in several ways:
The macro used to define object types has been expanded to
include several new data types and to enhance the documentation
associated with an object.
A new convention has been provided for creating and deleting
conceptual rows in a table.
2. One important MIB is defined as part of the SNMPv2 effort.
The SNMPv2 MIB contains basic traffic information about the
operation of the SNMPv2 protocol; this is analogous to the SNMP
group in MIB-II.
The SNMPv2 MIB also contains other information related to the
configuration of an SNMPv2 manager or agent.
3. The most noticeable change in protocol operations is the inclusion of two
new PDUs.
The GetBulkRequest PDU enables the manager to retrieve
large blocks of data efficiently.
The InformRequest PDU enables one manager to send trap
type of information to another.
24
1. Object Definitions in the SNMPv2 SMI are used to describe managed
objects. The ASN.1 macro OBJECT-TYPE is used to convey the syntax
and semantics of all managed objects in a systematic way.
2. DataTypes: either be simple or application-based.
Simple:
INTEGER (-2147483648..2147483647)
OCTET STRING (SIZE (0..65535))
OBJECT IDENTIFIER
Application:
IpAddress (32-bit)
Counter32 (2
32
- 1)
Counter64 (2
64
- 1)
Unsigned32 (0 .. 2
32
-1)
Gauge32 (2
32
-1)
TimeTicks
Opaque
BITS
3. UnitsPart
4. MAX-ACCESS Clause
5. STATUS Clause
6. Other Clauses: ReferPart, IndexPart, DefValPart, VALUE
NOTATION
25
1. SNMPv2 Tables
Table Definition:
o Tables that prohibit row creation and deletion by a manager
o Tables that allow row creation and deletion by a manager
Table Indexing
o The INDEX component of the row definition determines which object
values(s) will unambiguously distinguish one row in the table.
Row Creation and Deletion
o Define two new protocol data units, Create and Delete, to be used
for explicit row creation and deletion.
o Embed the semantics for row creation and deletion into the MIB with a
new textual convention called RowStatus. Row creation and deletion
is performed using set and get operations.
Access Category Restrictions
o The restriction differ, depending on whether or not the table supports
row creation and deletion by management stations.
2. Notification Definitions
The NOTIFICATION-TYPE macro is used to define the information that is sent
by an SNMPv2 entity when an exceptional event occurs at the entity.
3. Information Modules
OBJECT-TYPE and NOTIFICATION-TYPE
OBJECT-GROUP and MODULE-COMPLIANCE
AGENT-CAPABILITIES
26
1. Manager-agent request-response: An SNMPv2 entity acting in a manager
role sends a request to an SNMPv2 entity acting in an agent role, and the
latter SNMPv2 entity then responds to the request. This type is used to
retrieve or modify management information associated with the managed
device.
2. Manager-manger request-response: An SNMPv2 entity acting in a
manager role sends a request to an SNMPv2 entity acting in a manger role,
and the latter SNMPv2 entity then responds to the request. This type is
used to notify an SNMPv2 entity acting in a manager role of management
information associated with another SNMPv2 entity also acting in a
manager role.
3. Agent-manger unconfirmed: An SNMPv2 entity acting in a agent role
sends a unsolicited message, termed a "trap", to an SNMPv2 entity acting
in a manger role, and no response is returned. This type is used to notify an
SNMPv2 entity acting in a manager role of an exceptional event that has
resulted in changes to management information associated with the
managed device.
27
1. The use of the SNMPv1 message format as the outer wrapper for SNMPv2 PDUs is
referred to as community-based SNMPv2, or SNMPv2C. This means that, at present, any
security provided for SNMPv2 musk rely on the SNMPv1 community concept.
2. In general, an SNMPv2 entity performs the following actions to transmit a PDU to
another SNMPv2 entity:
1) The PDU is constructed, using the ASN.1 structure defined in the protocol specification.
2) This PDU is then passed to an authentication service, together with the source and destination
transport addresses and a community name. The authenticaiton service then perform any required
transformations for this exchange, such as encryption or the inclusion of an authentication code, and
return the results.
3) The protocol entity then constructs a message, consisting of a version field, the community name, and
the result from step 2).
4) This new ASN.1 object is then encoded, using the basic encoding rule (BER), and passed to the
transport service.
3. In general, an SNMPv2 entity performs the following actions upon reception of an
SNMPv2 message:
1) It does a basic syntax-check of the message and discards the message if it fails to parse.
2) It verifies the version number and discards the message if there is a mismatch.
3) The protocol entity then passes the user name, the PDU portion of the messages, and the source and
destination transport address (supplied by the transport service that delivered the message) to an
authentication service.
1) If authentication fails, the authentication service signals the SNMPv2 protocol entity,
which generates a trap and discards the message.
2) If authentication succeeds, the authentication service returns a PDU in the form of an
ASN.1 object that conforms to the structure defined in the protocol specification.
4) The protocol entity does a basic syntax-check of the PDU and discards the PDU if it fails to
parse.Otherwise using the named community, the appropriate SNMPv2 access policy is selected and
the PDU is processed accordingly.

28

version (1) community PDU
PDU
type
request
id
error status
or
nonrepeaters
error index
or
max-reps
variable-bindings
name 1
value 1 name 2
value 2
. . .
SNMPv2 message
SNMPv2 PDU
variable-binding
SNMPv2 message structure
29
1.The GetRequest, GetNextRequest, SetRequest and SNMPv2-
Trap PDUs have the same format as the Response and InformRequest
PDUs, with the error-status and error-index fields always set to 0. This
convention reduces by one the number of different PDU formats with which
the SNMPv2 entity must deal.
30
1. The SNMPv2 GetRequest PDU is identical, in format and semantics, to
the SNMPv1 GetRequest PDU. The only differences is in the way that
responses are handled.
The SNMPv1 GetRequest operation is atomic: Either all of the values are
retrieved or none is retrieved.
The SNMPv2, a variable-bindings list is prepared even if values can not be
supplied for all variables.
If the variable does not have an OBJECT IDENTIFIER prefix that exactly matches the
prefix of any variable accessible by this request, then its value field is set to
noSuchObject.
Otherwise, if the variable's name does not exactly match the name of a variable accessible
by this request, then its value field is set to noSuchInstance.
Otherwise, the value field is set to the value of the name variable.
2. The SNMPv2 GetNextRequest PDU is identical to the SNMPv1
GetNextRequest PDU, in format and semantics. As with the
GetRequest PDU, the only difference is that the SNMPv1
GetNextRequest is atomic, while the SNMPv2 GetNextRequest
process as many variables as possible.

31
1. The SNMPv2 GetBulkRequest PDU allows an SNMPv2 manager to
request that the response be as large as possible given the constraints on
message size.
2. The GetBulkRequest operation uses the same selection principle as the
GetNextRequest operation; that is, selection is always of the next
object instance in lexicographic order. The difference is that, with
GetBulkRequest, it is possible to specify that multiple lexicographic
successors be selected.
3. The GetBulkRequest PDU has two fields not found in the other PDUs:
nonrepeaters and max-repetitions. The non-repeaters
field specifies the number of variables in the variable-bindings list
for which a single lexicographic successor is to be returned. The max-
repeaters field specifies the number of lexicographic successors to be
returned for the remaining variables in the variable-bindings list.
4. The GetBulkRequest operation removes one of the major limitations
of SNMP, which is its inability to retrieve large blocks of data efficiently.
Moreover, this use of operator can actually enable reducing the size of
management applications that are supported by the management protocol,
realizing further efficiencies.
5. There is no need for the management application to concern itself with
some of the details of packing requests, it need not perform a trial-and-
error procedure to determine the optimal number of variable bindings to
put in a request PDU.
32
1. The SNMPv2 SetRequest PDU is identical to the SNMPv1
SetRequest PDU in format and semantics. The only difference is in the
way that response are handled.
2. The SNMPv2 set operation is atomic: Either all variables are updated or
none is.
3. If there is any error (12 conditions defined on Page 384) on any of the
variables, then a response PDU is issued with the error-status field
set appropriately and the value of the error-index field set to the index
of the failed variable bindings.
4. The use of a number of different error codes in an improvement over
SNMP; it enables a management station to more readily determine the
cause of a failed request and take the needed action to solve the problem.
5. If no validation errors are encountered, then an attempt is made to update
all of the variables in the SetRequest PDU.
6. If any assignment fails (despite the validation phase), then all assignments
are undone, and a response PDU is issued with an error-status of
commitFailed and the value of the error-index field set to the
index of the failed variable bindings.
7. If, however, it is not possible to undo all of the assignments, then a
response PDU is issued with an error-status of undoFailed and
the value of the error-index field set to zero.
33
1. The SNMPv2-Trap PDU is generated and transmitted by an SNMPv2
entity acting in an agent role when an unusual event occurs.
2. The SNMPv2-Trap PDU uses the same format as all other SNMPv2
PDUs except GetBulkRequest, thus easing the processing task at the
receiver.
3. As with the SNMP Trap PDU, no response is issued to an SNMPv2-
Trap PDU.
4. The InformRequest PDU is sent by an SNNPv2 entity acting in a
manager role, on behave of an application, to another SNMPv2 entity
acting in a manager role, to provide management information to an
application using the latter entity.
5. The InformRequest PDU includes a variable-bindings field
with the same elements as for the SNMPv2-Trap PDU.
6. There is no definition of how or when to use Report-PDU, because all of
the text on usage of Report-PDUs occurred in security-related documents
that were subsequently dropped.


34
1.The SNMPv2 document stats that UDP is the preferred maping.
35
1. The key design feature of the SNMPv2 SMI, from the viewpoint of
coexistence, is that modules defined using the current SNMPv1 SMI may
continue to be used with the SNMPv2 protocol. For the MIB modules to
conform to the SNMPv2 SMI, certain changes are necessary.
2. It is possible for an agent to maintain an SNMPv1 MIB unchanged and still
coexist in an SNMPv2-SNMPv1 environment.
3. The changes required for conformance to SNMPv2 fall into four
categories.
4. The major changes in protocol are an extension of the set of PDUs to
include the GetBulkRequest PDU and the InformRequest PDU,
and a change in semantics to allow get operations to provide partial results
rather than operate in an atomic manner.
5. The coexistence strategy deals with two issues: the use of the proxy agents
and bilingual manager behavior.
36
1.A description of the SNMPv2 MIB, which instruments both SNMPv2 and
SNMPv1.
2.Conformance statements are used to specify conformance requirements for
standardized MIBs and to enable vendors to document the scope of their
implementation.
3.The MIB extensions to the interfaces group are defined using SNMPv2
SMI and depend on some of the protocol features of SNMPv2.
37
1.System group: an expansion of the original MIB-II system group to include
a collection of objects allowing an SNMPv2 entity acting in an agent role to
describe its dynamically configurable object resources.
2.SNMP group: a refinement to the original MIB-II snmp group, consisting of
objects providing basic instrumentation of protocol activity.
3.MIB objects group: a collection of objects that deals with SNMPv2-Trap
PDUs and that allow several cooperating SNMPv2 entities, all acting in a
manger role, to coordinate their use of the SNMPv2 set operation.
4. The system group defined in the SNMPv2 MIB is actually the same group
defined in MIB-II, with the addition of some new objects, which are named
beginning with the prefix sysOR.
5.Those new objects related to system resources are used by an SNMPv2
entity acting in an agent role to describe those object resources that it controls
that are subject to dynamic configuration by a manager.
38
1.SNMP group is the same group defined in MIB-II but with the addition of
some new objects and the deletion of some of the original objects.
2.The snmp group contains some basic traffic information relating to the
operation of SNMPv2.
3.The revised group has far fewer parameters (Figure 13.2). The reason for
this is that these detailed statistics are not essential to debugging real problems
and they add quite a bit to the size of an agent. Accordingly, a more
streamlined group of objects was adopted.
39
1.The MIB objects group contains additional objects pertinent to the control of
MIB objects (Figure 13.3).
snmpTrap:
snmpTrap0ID, which is the object identifier of the trap or
notification currently being sent.
snmpTrapEnterprise, which is the object identifier of the
enterprise associated with the trap currently being sent.
snmpSet:
snmpSerialNo, which is used to solve two problems that can
occur with the use of the set operation.
Multiple set operation on the same MIB object may be
issued by a manager, and it may be essential that these
operations be performed in the order that thy were
issued, even if they are reordered in transmission.
Concurrent use of set operations by multiple managers
may result in an inconsistent or inaccurate database.
40
1.The purpose of the conformance statement document is to define a notation
to be used to specify acceptable lower bounds of implementation, along with
the actual level of implementation achieved.
2.OBJECT-GROUP: indicates those objects in a MIB module that are part of
a conformance group.
3.NOTIFICATION-GROUP: identifies a collection of notification.
4.MODULE-COMPLIANCE: defines compliance requirements for an agent
with respect to MIB modules and objects.
5.AGENT-CAPABILITIES: defines the capabilities provided by a particular
agent implementation.
41
1.The SNMPv2 specification specifies that an object is "implemented" only if
a reasonably accurate value can be returned for a read operation.
2.For writable object, the implementation must be able reasonably to influence
the underlying managed entity in response to a set operation.
3.If an agent cannot implement an object, it must return an error, such as
noSuchObject, in response to a protocol operation.
4.The agent is not permitted to return a value for an object that it does not
implement.
42
43
44
1.A formal definition of agent capabilities can be useful in promoting and
optimizing interoperability. If a management station has the capabilities
statement for each of the agents with which it interacts, it can adjust its
behavior accordingly to optimize the use of resources: its own, the agent's, and
the network's.
45
RFC1573 notes the following problem areas:
1. Interface numbering:
2. Interface sublayers:
3. Virtual circuits:
4. Bit, character and fixed-length interfaces:
5. Counter size:
6. Interface speed:
7. Multicast/broadcast counters:
8. Addition of new ifType values:
9. ifSpecific:
RFC1573 added four new tables:
1. Extensions table (ifXTable)
2. Stack table (ifStackTable)
3. Test table (ifTestTable)
4. Receive address table (ifRcvAddressTable)
46
1. The existence of multiple rows in ifTable for a single physical interface
is allowed, with one row per logical sublayers.
2. Several objects, like ifInNucastPkts, ifOutNucastPkts and
ifSpecific, have been deprecated.
3. Another change to ifTable is that the syntax of ifType is changed to
be the textual convention IANAifType, which can be respecified (with
additional values) without issuing a new version of the MIB.
4. IANA -- Internet Assigned Number Authority, is responsible for updating
IANAifType as needed.
47
48
49
50
1.The table consists of three columnar objects:
ifRcvAddressAddress: a specific unicast, multicast or
broadcast address that the system will recognize as an appropriate
destination address for capturing packets.
ifrcvAddressStatus: used to create and delete rows in this
table; has the syntax RowStatus.
ifRcvAddressType: indicates whether the address is
other(1), volatile(2) or nonVolatile(3) (A nonvolatile
address will continue to exist after a system restart, whereas a volatile
address will be lost. An address labeled as other indicates that this
information is not being made available in this table.)
51
1. The SNMPv2 specification includes a strategy statement for evolution
from SNMPv1 to SNMPv2 by means of a period of coexistence. The two
elements of that strategy are as follows:
Minor changes to an SNMPv1 MIB are needed to bring it into
conformance with SNMPv2 SMI.
A mix SNMPv1/SNMPv2 environment can be managed by using a
proxy agent that communicates with SNMPv2 managers and
SNMPv1 agents, or by using bilingual managers.
52
1.The four macros are defined in the conformance statement document:
OBJECT-GROUP: indicates those objects in a MIB module that are
part of a conformance group.
NOTIFICATION-GROUP: identifies a collection of notifications.
MODULE-COMPLIANCE: defines compliance requirements for an
agent with respect to MIB modules and objects.
AGENT-CAPABILITIES: defines the capabilities provided by a
particular agent implementation.
53
This chapter will cover the four Cryptographic Algorithms used in SNMPv3,
SNMP Architecture, SNMPv3 Applications and MIBs
54
55
1. A conventional encryption scheme has five ingredients:
Plaintext: This is the readable message or data that is fed into the algorithm as
input.
Encryption algorithm: The encription algorithm performs various substitutions
and transformations on the plaintext.
Secret key: The secret key is also input to the algorithm. The exact substitutions
and transformation performed by the algorithm depend on the key.
Ciphertext: This is the scrambled message produced as output. It depends on the
plaintext and the secret key. For a given message, two different keys will
produce two different ciphertexts.
Description algorithm: This is essentially the encryption algorithm run in
reverse. It takes the ciphertext and the same secret key and produces the original
plaintext.
2. Two requirements for secure use of conventional encryption:
A strong encryption algorithm is required.
Sender and receiver must have obtained copies of the secret key in
a secure fashion and must keep the key secure.
3. Two ways to attack a conventional encryption scheme:
Cryptanalysis
Brute-force
56
Initial permutation
Round 1
Round 2
Round 16
Permuted Choice 2
Permuted Choice 2
Permuted Choice 2
Permuted Choice 1
Left circular shift
Left circular shift
Left circular shift
32-bit swap
Inverse initial
permutation
63-bit plaintext
56-bit key
63-bit ciphertext
K
1
K
2
K
16
General depiction of DES
encryption algorithm
57
1.To produce the first block of ciphertext, an initialization vector (IV) is
XORed with the first block of plaintext. On decryption, the IV is XORed with
the output of the decryption algorithm to recover the first block of plaintext.
2.The IV must be known to both the sender and receiver. For maximum
security, the IV should be protected as well as the key. This could be done by
sending the IV using ECB encryption.
58
1. MD5 was the most widely used secure hash algorithm now.
2. The MD5 message-digest algorithm (RFC 1321) was developed by Ron
Rivest at MIT.
3. The algorithm takes as input a message or arbitrary length and produces as
output a 128-bit message digest.
4. The input is processed in 512-bit blocks.
5. The processing consists of the following steps:
Append padding bits.
Append length
Initialize MD buffer
Process message in 512-bit (16-word) blocks
Output
6. The MD5 algorithm has the property that every bit of the hash code is a
function of every bit in the input.
7. The complex repetition of the basic function (F, G, H, I) produces results
that are well mixed.
59
1. The processing of a message is similar to MD5, with a block length of 512
bits and a hash length and chaining variable length of 160 bits.
2. The processing consists of the following steps:
Append padding bits
Append length
Initialize MD buffer
Process message in 512-bit (16-word) blocks
Output
60
1. Message Authentication Code
A. A MAC algorithm involves the use of a secret key to generate a small block of data,
known as a message authentication code, that is appended to the message.
B. A number of algorithms could be used to generate the code. (DES).
2. HMAC
A. Design Objectives
a) Easy to use
b) Essy to be replaced
c) Preseve the performance
d) Handle the key simply
e) Have a well-understood authentication mechanism
B. Algorithm
a) Append zeros to the left end of K to create a b-bit string K
+
b) XOR K
+
with ipad to produce the b-bit block S
i
c) Append M to S
i
d) Apply H to the stream generated in step C
e) XOR K
+
with opad to produce the b-bit block S
o
f) Append the hash result from step D to S
o
g) Apply H to the stream generated in step F and output the result.
C. Security
a) Based on an embedded hash function depends in some way on the cryptographic
strength of the underlying hash function.
60
61
SGMP
SNMPv1
RMON MIB
SNMPv2
Working group
SNMPv2
(original version; with security)
Secure SNMP
SNMPv2 security
working group
SNMPv2
(revised version;
without security)
SNMPv2u
SNMPv2*
SNMPv3
The evolution of SNMP
62
1. Several design decisions:
1) Architecture
2) Self-contained documents
3) Remote configuration
4) Controlled complexity
5) Treats
6) Modification of information
7) Masquerade
8) Message stream modification
9) Disclosure
2. SNMPv3 is not intended to secure against the following two threats:
1) Denial of service
2) Traffic analysis.
63
Document
roadmap*
Applicability
statement*
Coexistence
and transition*
Message Handling
Transport
mappings
Message
processing and
dispatcher
Security
PDU Handling
Protocol
operations
Applications Access control
Structure of
management
information
Textual
conventions
Conformance
Statements
MIBs
Standard v1
RFC 1157
format
Standard v1
RFC 1212
format
Historic RFC
1442, 1443, and
1444 format
Draft RFC 1902,
1903, and 1904
format
Information Model
64
Command
generator
Notification
receiver
Command
responder
Notification
originator
Other
Proxy
forwarder
Dispatcher Message
processing
subsystem
Security
subsystem
Access
control
subsystem
SNMP Engine (identified by snmpEngineID)
Application(s)
SNMP Entity (RFC 2271)
65
Command
generator
applications
Command
generator
applications
Command
generator
applications
PDU
dispatcher
Message
dispatcher
Transport mapping
(e.g., RFC 1906)
v1MP
V2cMP
V3MP
OtherMP
User-based
security
model
Other
Security
model
Message Processing
Subsystem
Security
Subsystem
SNMP Applications
Dispatcher
SNMP Engine
Proxy
forwarder
application
Command
responder
applications
Notification
originator
applications
PDU
dispatcher
Message
dispatcher
Transport mapping
(e.g., RFC 1906)
v1MP
V2cMP
V3MP
OtherMP
User-based
security
model
Other
Security
model
Message Processing
Subsystem
Security
Subsystem
MIB instrumentation
Dispatcher
SNMP Application
View-based
access
control
model
Other
access
control
model
Access
Control
Subsystem
SNMP Engine
Traditional SNMP Agent
Traditional SNMP manager
66
67
68
69
70
71
72
73
1.VACM: View-Based Access Control Model
74
75