This is a MIB Module for monitoring the structures
and status of IPSec-based networks. The MIB has been
designed to be adopted as an IETF standard. Hence
vendor-specific features of IPSec protocol are excluded
from this MIB.
Acronyms
The following acronyms are used in this document:
IPsec: Secure IP Protocol
VPN: Virtual Private Network
ISAKMP: Internet Security Association and Key Exchange
Protocol
IKE: Internet Key Exchange Protocol
SA: Security Association
(ref: rfc2408).
SPI: Security Parameter Index is the pointer or
identifier used in accessing SA attributes
(ref: rfc2408).
MM: Main Mode - the process of setting up
a Phase 1 SA to secure the exchanges
required to setup Phase 2 SAs
QM: Quick Mode - the process of setting up
Phase 2 Security Associations using
a Phase 1 SA.
Phase 1 Tunnel:
An ISAKMP SA can be regarded as representing
a flow of ISAKMP/IKE traffic. Hence an ISAKMP
is referred to as a 'Phase 1 Tunnel' in this
document.
Control Tunnel:
Another term for a Phase 1 Tunnel.
Phase 2 Tunnel:
An instance of a non-ISAKMP SA bundle in which all
the SA share the same proxy identifiers (IDii,IDir)
protect the same stream of application traffic.
Such an SA bundle is termed a 'Phase 2 Tunnel'.
Note that a Phase 2 tunnel may comprise different
SA bundles and different number of SA bundles at
different times (due to key refresh).
MTU:
Maximum Transmission Unit (of an IPsec tunnel).
History of the MIB
A precursor to this MIB was written by Tivoli and implemented
in IBM Nways routers in 1999. During late 1999, Cisco adopted
the MIB and together with Tivoli publised the IPsec Flow
Monitor MIB in IETF IPsec WG in
draft-ietf-ipsec-flow-monitoring-mib-00.txt. In 2000, the
MIB was Cisco-ized and implemented this draft as
CISCO-IPSEC-FLOW-MONITOR-MIB in IOS and VPN3000 platforms.
With the evolution of IKEv2, the MIB was modified and
presented to the IPsec WG again in May 2003 in
draft-ietf-ipsec-flow-monitoring-mib-02.txt.
With the emergence of multiple IPsec signaling protocols,
it became apparent that the signaling aspects of IPsec
need to be instrumented separately in their own right.
Thus, the IPsec control attributes and metrics were
separated out into CISCO-IPSEC-SIGNALING-MIB and
CISCO-IKE-FLOW-MIB.
This version of the draft is the version of the draft
that models that IPsec data protocol, structures and
activity alone.
Overview of MIB
The MIB contains four major groups of objects which are
used to manage the IPsec Protocol. These groups include
a Levels Group, a Phase-1 Group, a Phase-2 Group,
a History Group, a Failure Group and a TRAP Control Group.
The following table illustrates the structure of the
IPsec MIB.
The Phase 2 group models objects pertaining to
IPsec data tunnels.
The History group is to aid applications that do
trending analysis.
The Failure group is to enable an operator to
do troubleshooting and debugging of the VPN Router.
Further, counters are supported to aid detection
of potential security violations.
In addition to the three major MIB Groups, there are
a number of Notifications. The following table
illustrates the name and description of the
IPsec TRAPs.
ication is generated when an IPsec Phase-2
Tunnel becomes active.
ciscoEnhIpsecFlowTunnelStop
.1.3.6.1.4.1.9.9.432.0.2
ication is generated when an IPsec Phase-2
Tunnel becomes inactive.
ciscoEnhIpsecFlowSysFailure
.1.3.6.1.4.1.9.9.432.0.3
ication is generated when the processing
for an IPsec Phase-2 Tunnel experiences an internal
or system capacity error.
ciscoEnhIpsecFlowSetupFail
.1.3.6.1.4.1.9.9.432.0.4
ication is generated when the setup for
an IPsec Phase-2 Tunnel fails.
ciscoEnhIpsecFlowBadSa
.1.3.6.1.4.1.9.9.432.0.5
ication is generated when the managed
entity receives an IPsec packet with a non-existent
(non-existant in the local Security Association
Database) SPI.
ciscoEnhIpsecFlowCertExpiry
.1.3.6.1.4.1.9.9.432.0.6
ication is generated to notify that an X.509
certificate is going to expire. The notification is triggered
the time threshold configured on the application for
notification before the certificate is going to expire, which
is when the value of ceipSecCertExpiryStatus is changed from
certOK(1) to certGoingExpired(2). The user should take action
to renew the certificate identified in the notification prior
to the certificate expiration, which is at the validity
notAfter time provided in the notification.
ciscoEnhIpsecFlowCertRenewal
.1.3.6.1.4.1.9.9.432.0.7
ication is generated to report a status transition
for an X.509 certificate renewal performed by the application.
The notification is generated when the value of
ceipSecCertRenewalStatus is changed from
1. renewalNotNeeded(1) to renewalRequestNeeded(2) or
renewalRequested(3)
2. renewalRequestNeeded(2) to renewalRequested(3)
3. renewalRequested(3) to renewalSuccess(4) or
renewalFailedUpdate(5) or renewalFailedExpired(6)
4. renewalFailedUpdate(5) to renewalFailedExpired(6)