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.