Network Services Monitoring MIB
obsoletes
- rfc-2248 — Network Services Monitoring MIB
Extracted elements (25)
applDirectoryName serves as an external key linking an SNMP MIB entry to the X.500 Directory, enabling static configuration information to be stored and retrieved from the directory rather than replicated in the MIB.
Only static information in applTable is the application name; all other static configuration should be obtained from directory services. This keeps the MIB focused on operational monitoring rather than configuration.
RFC 2788 changed applName, applVersion, and applDescription from DisplayStrings to SnmpAdminStrings rather than deprecating old objects and adding new ones, because the latter approach would have caused greater backward compatibility and interoperability harm given these objects' semantics.
The MIB is designed as a building block providing only attributes common to all network service applications. Application-specific monitoring (e.g., MTA, DSA) is handled by separate extension MIBs that augment this common base.
The MIB is intentionally restricted to read-only, simple monitoring. Capabilities such as configuration control, queue inspection, request probing, and forcing actions were deliberately excluded because they would require strict security checking and complex, implementation-specific designs.
A MIB conforming to SMIv1 can be produced from this SMIv2 module via appropriate translation, with the caveat that Counter64 objects cannot be represented and machine-readable information is converted to textual descriptions, but semantics are considered preserved.
For assocRemoteApplication, IP-based applications should use a domain name or IP address; OSI applications should use a string-encoded Distinguished Name; X.400(1984) MTAs without a DN may use RFC 2156 'mta in globalid' syntax.
RFC 2788 defines three versioned compliance levels (RFC1565, RFC2248 [deprecated], RFC2788 [current]) with distinct OBJECT-GROUPs. RFC 2788 adds applDirectoryName to the application group that was missing from RFC 2248.
Each network service application capable of being monitored should have a single entry in applTable.
Implementers are recommended to use the SNMPv3 User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575) to control access to this MIB.
applDirectoryName holds the Distinguished Name of the X.500 directory entry for static configuration information about the application. An empty string indicates no directory entry exists.
applRejectedInboundAssociations counts only rejections performed by the application entity itself since initialization; it does not count rejections at lower network layers, so may undercount true failed inbound associations.
applUptime, applLastChange, applLastInboundActivity, applLastOutboundActivity, and assocDuration all use TimeStamp (value of sysUpTime at the relevant moment); a zero value indicates the event occurred prior to the last initialization of the network management subsystem.
applURL holds a URLString pointing to a human-readable description of the application, intended for use in status displays.
assocApplicationProtocol uses an OBJECT IDENTIFIER to identify the protocol in use. For TCP-based protocols, OIDs of the form {applTCPProtoID port} are used; for UDP-based protocols, {applUDPProtoID port}. For OSI applications, the Application Context OID is used.
assocApplicationType is an INTEGER enumeration with four values: uainitiator(1), uaresponder(2), peerinitiator(3), peerresponder(4), indicating whether the remote end is a user agent or peer and whether it initiated or responded to the connection.
The applTable contains one row per operational network service application on the system, indexed by applIndex. It holds name, directory reference, version, uptime, operational status, association counts, and URL for each application.
The assocTable holds one entry per active application association, indexed by applIndex and assocIndex. Each entry records the remote application name, protocol OID, association type (UA or peer, initiator or responder), and start timestamp.
applTCPProtoID ({application 4}) and applUDPProtoID ({application 5}) define OID namespaces for identifying TCP-based and UDP-based application protocols respectively, using port number as a sub-identifier (e.g., {applTCPProtoID 25} for SMTP).
All objects in this MIB are read-only (MAX-ACCESS read-only); there are no read-write or read-create objects. Consequently, there is no risk that an intruder can alter or create management objects via SNMP SET operations.
SNMPv1 alone is not a secure environment; even on a network secured with IPsec there is no control over which hosts on that network may GET objects from this MIB. SNMPv3 with USM and VACM is recommended to enforce per-principal access control.
The MIB exposes passive information about the existence, type, and configuration of applications on a host, which could indicate vulnerabilities, and information about network usage that could be used for traffic pattern analysis.
applOperStatus defines six operational states for a network service application: up (available), down (unavailable), halted (operational but not available), congested (no additional inbound associations), restarting (unavailable but recovering), and quiescing (shutting down, may reject new inbound associations).
DistinguishedName is a textual convention encoded as an OCTET STRING of SIZE 0..255, representing an X.500 distinguished name per RFC 2253 in UTF-8 charset (RFC 2279).
URLString is a textual convention encoded as an OCTET STRING of SIZE 0..255, representing a URL per RFCs 1738 and 2368 in NVT ASCII charset (RFC 854).