[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Internet Engineering Task Force                              Tim Jenkins
IP Security Working Group                           TimeStep Corporation
Internet Draft                                          October 19, 1998




                          IPSec Monitoring MIB
                     <draft-ietf-ipsec-mib-01.txt>

Status of this Memo

   This document is a submission to the IETF Internet Protocol Security
   (IPSEC) Working Group. Comments are solicited and should be addressed
   to the working group mailing list (ipsec@tis.com) or to the editor.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Copyright Notice


   This document is a product of the IETF's IPSec Working Group.
   Copyright (C) The Internet Society (1998).  All Rights Reserved.










IPSec Working Group                                             [Page 1]


Internet Draft           IPSec Monitoring MIB               October 1998


Table of Contents


   1. Revision History                                                 2
   2. Introduction                                                     3
   3. The SNMPv2 Network Management Framework                          3
   3.1 Object Definitions                                              4
   4. IPSec MIB Objects Architecture                                   5
   4.1 Tunnel MIB and Interface MIB Consideration                      5
   4.2 MIB Tables                                                      6
   4.3 IPSec Virtual Tunnels                                           7
   4.3.1 Transient Tunnels                                             9
   4.3.2 Permanent Tunnels                                             9
   4.4 IKE SA Tunnels                                                 10
   4.5 Phase 2 SA Tunnels                                             11
   4.6 Phase 2 SAs                                                    12
   4.7 Asymmetric Use                                                 12
   4.8 IPSec MIB Traps                                                12
   4.9 IPSec Device MIB                                               13
   5. MIB Definitions                                                 14
   6. Security Considerations                                         43
   7. Acknowledgements                                                43
   8. References                                                      44
   9. Editor's Address                                                46

1. Revision History

   This section will be removed before publication.

   September 11, 1998    Initial internal release.
                         Traps not yet defined in ASN.1 format.
                         Device MIB not yet defined in ASN.1 format.

   October 4, 1998       Added significantly more explanations on tunnel
                         concept, including picture.
                         Added packet counters for traffic.
                         Made time usage consistent.
                         Added generic error counters.
                         Added SPIs and CPIs to IPSec SA table, and
                         cookies to IKE SA tunnel table.
                         Added peer port number to IKE SA table.
                         Added peer's certificate serial number and
                         issuer to IKE SA table.
                         More information about traps.
                         Added policy enforcement errors to IPSec
                         tunnels.




IPSec Working Group                                             [Page 2]


Internet Draft           IPSec Monitoring MIB               October 1998


                         Issues:
                         1) Do aggregate statistic values on permanent
                         tunnels restart if link goes down and comes
                         back up again?
                         2) Should the IKE SA table indicate who was the
                         initiator?
                         3) Still have not put traps into ASN.1 format.
                         4) Still have not put entity-wide statistics
                         into ASN.1 format.


2. Introduction

   This document defines monitoring and status MIBs for IPSec. It does
   not define MIBs that may be used for configuring IPSec
   implementations or for providing low-level diagnostic or debugging
   information. Further, it does not provide policy information. Those
   MIBs may be defined in later versions of this document or in other
   documents.

   The purpose of the MIBs is to allow system administrators to
   determine operating conditions and perform system operational level
   monitoring of the IPSec portion of their network. Statistics are
   provided as well.

   The IPSec MIB definitions use a virtual tunnel model, of which there
   can be configured permanent tunnels or transient tunnels. The virtual
   tunnel model is used to allow the use of IPSec from a virtual private
   networking (VPN) point of view. This allows users of IPSec based
   products to get similar monitoring and statistical information from
   an IPSec based VPN as they would from a VPN based on other
   technologies, such as Frame Relay.

   Finally, the objects defined perhaps represent a somewhat simplified
   view of security associations. This is done for the purposes of
   expediency and for simplification of presentation. Also, some
   information about SAs has been intentionally left out to reduce the
   security risk if SNMP traffic becomes compromised.


3. The SNMPv2 Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o An overall architecture, described in RFC 2271 [2271].




IPSec Working Group                                             [Page 3]


Internet Draft           IPSec Monitoring MIB               October 1998


   o Mechanisms for describing and naming objects and events for the
     purpose of management. The first version of this Structure of
     Management Information (SMI) is called SMIv1 and described in
     RFC 1155 [1155], RFC 1212 [1212] and RFC 1215 [1215]. The second
     version, called SMIv2, is described in RFC 1902 [1902],
     RFC 1903 [1903] and RFC 1904 [1904].

   o Message protocols for transferring management information. The
     first version of the SNMP message protocol is called SNMPv1 and
     described in RFC 1157 [1157]. A second version of the SNMP message
     protocol, which is not an Internet standards track protocol, is
     called SNMPv2c and described in RFC 1901 [1901] and
     RFC 1906 [1906]. The third version of the message protocol is
     called SNMPv3 and described in RFC 1906 [1906], RFC 2272 [2272]
     and RFC 2274 [2274].

   o Protocol operations for accessing management information. The
     first set of protocol operations and associated PDU formats is
     described in RFC 1157 [1157]. A second set of protocol operations
     and associated PDU formats is described in RFC 1905 [1905].

   o A set of fundamental applications described in RFC 2273 [2273] and
     the view-based access control mechanism described in
     RFC 2275 [2275].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.


3.1 Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1)
   defined in the SMI. In particular, each object type is named by an
   OBJECT IDENTIFIER, an administratively assigned name. The object type
   together with an object instance serves to uniquely identify a


IPSec Working Group                                             [Page 4]


Internet Draft           IPSec Monitoring MIB               October 1998


   specific instantiation of the object. For human convenience, we often
   use a textual string, termed the descriptor, to refer to the object
   type.


4. IPSec MIB Objects Architecture

   The IPSec MIB provides information related to both phase 1 or
   Internet Key Exchange (IKE) security associations (SAs) and phase 2
   (or IPSec) SAs. Configuration about the SAs is provided as are
   statistics related to the SAs themselves.

   Since one of the uses of IPSec implementations is to provide Virtual
   Private Network (VPN) services that other private network services
   such as leased lines or frame relay networks, there exists a need to
   provide the same type of monitoring capability.

   To support this, the concept of virtual tunnels is developed.
   Additionally, the concept of transients and permanent tunnels is also
   developed.


4.1 Tunnel MIB and Interface MIB Consideration

   It should be noted that the MIBs here are not extensions of the
   Tunnel MIB [IPTun] or the Interface Group MIB [IGMIB]. That approach
   was rejected for a number of reasons, including:

   o The types of parameters required for those MIBs are not appropriate
     for IPSec MIBs.

   The parameters required for IPSec tunnels are related to security
   services and statistics associated with handling those services.
   There no parameters like that associated with the Tunnel MIB.

   o The virtual tunnels created by IPSec SAs are independent of other
     logical interfaces.

   This document takes the point of view that IPSec sits on top of IP.
   This perspective is used since IPSec adds additional protocol headers
   before the IP header. In this case, it may be conceptually viewed as
   a layer 4 protocol from the IP layer point of view. As such, the
   handling of IPSec secured packets by IP is independent of how IP is
   routed over the physical or logical layer 2 interfaces. That
   particular mapping is part of the purpose of the Tunnel MIB, and thus
   has no direct relationship on the IPSec virtual tunnels.




IPSec Working Group                                             [Page 5]


Internet Draft           IPSec Monitoring MIB               October 1998


   o The tunnel end point definitions are not the same as those used by
     the tunnel MIB.

   The Tunnel MIB uniquely defines tunnels by a simple source and
   destination IP address pair. This is only a specific subset of the
   identifiers needed for IPSec virtual tunnels.


4.2 MIB Tables

   The MIB uses three tables that are linked as shown in Figure 4-1. The
   following sections describe the use of these tables.

   The IPSec SAs appear in the IPSec SA table. These SAs create the
   virtual tunnels shown in the IPSec virtual tunnel table. These may
   have been created by SAs in the IKE SA table, which is also
   considered a virtual tunnel, and contains statistics about itself,
   the IKE SAs used to support it, and aggregate information about IPSec
   virtual tunnels created by it.

   In Figure 4-1, IKE virtual tunnel number 1 has created two IPSec
   virtual tunnels 1 and 2. Virtual tunnel 1 at this moment has SAs
   numbered 1 and 6, while virtual tunnel 2 at this moment has SAs
   numbered 2 and 5. IKE virtual tunnel number 2 has created IPSec
   virtual tunnel 3, which has IPSec SAs numbered 3 and 4.


ipsecIkeSaTable      -information and statistics on the IKE SAs
    IKE SA1 <---+    -aggregate information about IPSec tunnels
    IKE SA2 <-+ |
              | |<- only if IPSec SAs are not static
              | |
              | | ipsecTunnelTable      -information and statistics on
              | +- IPSec Tunnel 1 <---+  the IPSec virtual tunnels
              | +- IPSec Tunnel 2 <--+|
              +--- IPSec Tunnel 3 <-+||
                                    |||
                                    ||| ipsecSaTable -information on
                                    ||+- IPSec SA 1   specific IPSec SAs
                                    |+|- IPSec SA 2
                                    +||- IPSec SA 3
                                    +||- IPSec SA 4
                                     +|- IPSec SA 5
                                      +- IPSec SA 6

               Figure 4-1 IPSec Monitoring MIB Structure




IPSec Working Group                                             [Page 6]


Internet Draft           IPSec Monitoring MIB               October 1998


   A diagram that is intended to show the tunnels that exist between two
   IPSec gateways is shown in Figure 4-2. Two host groups each are shown
   behind the IPSec gateways. Also shown are the IKE or phase 1 virtual
   tunnel between the gateways and four possible IPSec virtual tunnels.
   Of these four possible virtual tunnels, one is shown with two IPSec
   SAs in it. One of these SAs may be just about to expire, while the
   other may have been created in anticipation of the expiration of the
   first. These SAs are the SAs that provide the service, supporting the
   existence of the tunnel.

   Within each IPSec virtual tunnel are the IPSec SAs that are set up to
   maintain the virtual tunnels. Also illustrated is the link to the
   phase 1 SA tunnel that collects the aggregate statistics associated
   with all IPSec virtual tunnels associated with the IKE tunnel.

   More information on the virtual tunnels is presented in subsequent
   sections.


4.3 IPSec Virtual Tunnels

   IPSec implementations effectively create tunnels that user traffic
   may pass through, performing various services on that traffic as it
   passes through the tunnel.

   Virtual IPSec tunnels are created by the existence of SAs, either
   statically created, or created by IKE. The tunnel concept comes from
   the effect of SAs on packets that are handled by SAs. As a packet
   encounters an IPSec implementation, either in a security gateway or
   as layer in a protocol stack, a policy decision causes the packet to
   be handed to an SA for processing.

   The SA then performs a security service (including possibly
   compression) on the packet, then adds at least one new header and
   sends the packet into the normal IP stream for routing. (The only
   time no header is added is when the only service provided by the SA
   is compression, it is a transport mode SA, and the packet is not
   compressible.)

   When the secured (and possibly compressed) packet arrives at its
   destination, the peer IPSec implementation removes the added header
   or headers and reverse processes the packet. Another policy lookup is
   then done to make sure the packet was appropriately handled by the
   sending peer.

   Since the original packet is conceptually "hidden" between the two
   IPSec implementations, it can be considered tunneled. To help



IPSec Working Group                                             [Page 7]


Internet Draft           IPSec Monitoring MIB               October 1998


   conceptually, if ESP could be negotiated with no encryption and no
   authentication, it would provide services very similar to IP-in-IP.

               +----------------------------+
               |  IKE (control tunnel)      |
               |  +---------------------+   |
               |  |  IKE SA             |   |
               |  +---------------------+   |
               +----------------------------+
                                  ^  ^
                                  |  | <- aggregate IPSec statistics
                                  |  |
 H11 -|    +----+                 |  |    +----+      |- H21
      |    |    |                         |    |      |
      |----| G1 |-------------------------| G2 |------|
      |    |    |                         |    |      |
 H12 -|    +----+                 |  |    +----+      |- H22
                                  |  |
                                  |  |
         +-----------------------------------------+
         |      H11 to H21 (data tunnel)           | <- aggregate
         | +-------------------------------------+ |    SA statistics
         | | IPSec SA with H11 and H21 selectors | |    for H11-H21
         | +-------------------------------------+ |
         | +-------------------------------------+ |
         | | IPSec SA with H11 and H21 selectors | |
         | +-------------------------------------+ |
         +-----------------------------------------+
                                  |  |
         +-----------------------------------------+
         |      H11 to H22 (data tunnel)           | <- aggregate
         +-----------------------------------------+    SA statistics
                                  |  |                  for H11-H22
         +-----------------------------------------+
         |      H12 to H21 (data tunnel)           | <- aggregate
         +-----------------------------------------+    SA statistics
                                  |  |                  for H12-H21
         +-----------------------------------------+
         |      H12 to H22 (data tunnel)           | <- aggregate
         +-----------------------------------------+    SA statistics
                                  |  |                  for H12-H22
                                  +--+

                Figure 4-2 Illustration of IPSec Tunnels


   The specific SA chosen by the policy lookup is based on what are
   called the selectors. The selectors are the packet's source IP


IPSec Working Group                                             [Page 8]


Internet Draft           IPSec Monitoring MIB               October 1998


   address, its destination IP address, its layer 4 protocol and its
   layer 4 protocol source and destination port numbers. The policy
   system uses this information to assign the packet to an SA for
   handling.

   Since it is irrelevant to the packet which specific SA provided the
   services, and since all SAs with same selectors should provide the
   same service, the existence of any and all SAs assigned to the
   selector effectively creates a tunnel for the packets.

   In other words, the tunnel created by the SAs is identified by the
   selectors used to assign the security services to the packet. The
   selectors are explained in detail in [SECARCH].

   While the virtual tunnel described so far is for packets that are
   passed to the IPSec SAs, there exists another type of virtual tunnel.
   This virtual tunnel carries control traffic for the management of the
   IPSec SAs between two peers.

   This tunnel is created by the existence of phase 1 SAs between the
   two peers. This document assumes that there is never more than one
   phase 1 SA between peers for the purposes of the statistics provided
   by the phase 1, or IKE, tunnel. This allows the statistics for IKE
   SAs and the virtual tunnel created by those SAs to be combined into
   the same table.


4.3.1 Transient Tunnels

   Transient tunnels are made up of SAs that normally go up and down,
   such as those created by a dial-in client implementation.
   Additionally, these SAs are prone to being torn down in an impolite
   manner. As an example, system administrators typically do not want to
   have alarms going off when these SAs are torn down because an end
   user disconnected his or her modem before performing a normal dial-up
   networking shut down.

   By necessity, this applies to both the IKE tunnel and the IPSec
   tunnels created by it. Static SAs can never create transient tunnels.


4.3.2 Permanent Tunnels

   Permanent tunnels are made up of SAs that a system administrator
   considers of significant importance in a VPN implementation. These
   SAs would typically be from one IPSec gateway to another and be used
   as the link between two corporate networks. As such, the network



IPSec Working Group                                             [Page 9]


Internet Draft           IPSec Monitoring MIB               October 1998


   administrator would want alarms to go off when one of these virtual
   tunnels goes down under any circumstance.

   How implementations specify which tunnels are permanent versus
   transient is beyond the scope of this document.

   To determine if a particular permanent tunnel is up, the value of
   'ipsecTunnelCurrentSaNum' in the ASN.1 notation to follow must be
   greater than 0.


4.4 IKE SA Tunnels

   Phase 1 or IKE tunnels are defined as being made up of a series of
   phase 1 SAs that carry secured management traffic. It is assumed that
   only one phase 1 SA can exist between any two peers. Therefore, there
   is no separate table of phase 1 SAs and phase 1 SA tunnels.  A tunnel
   can be considered to exist past the lifetime of a phase 1 SA if a
   subsequent phase 1 SA can be immediately formed between the same
   peers, and any phase 2 SAs created by previous phase 1 SAs are not
   deleted when the original phase 1 SA expires. Stated another way,
   successful re-keying of a phase 1 SA keeps a phase 1 tunnel alive,
   but only if all phase 2 SAs created are kept as well.

   Phase 1 tunnels are uniquely identified by the IP addresses and port
   numbers of the end points. It is assumed that a peer that either
   initiates from or responds from a port number that is not the IKE
   default port number will continue to use the same port number.

   IKE SAs are displayed as a table. It is assumed that there is only a
   single SA between end points. Therefore, the table consists of all
   active phase 1 SAs that are established between the local entity and
   other entities.

   Each row of the table contains configuration information such as the
   encryption algorithm used, the key length, and the authentication
   algorithm used. Peer information, such as the peer ID is also
   provided. Certificate information, specifically the issuer name and
   serial number is included, even though it is meaningless in pre-
   shared key authentication mode. This is due to the importance of this
   information in many VPN implementations. The distinguished name of
   the certificate is not provided; it may be the ID used for phase 1
   negotiation. If the ID used for phase 1 negotiation is not the
   certificate's distinguished name, it should be one of the alternate
   names encoded in the certificate.

   Phase 1 tunnels may be transient or permanent. The status column has
   no meaning for a transient phase 1 tunnel, since it indicates a


IPSec Working Group                                            [Page 10]


Internet Draft           IPSec Monitoring MIB               October 1998


   tunnel that is up or down. A transient tunnel disappears from the
   table when it goes down; a permanent tunnel does not.

   It is recommended that implementations place permanent SAs in the
   table before all transient SAs, and that the order of permanent SAs
   displayed in the table does not change.

   Statistics are provided as well. There are three types of statistics
   provided. These are the statistics associated with the current phase
   1 SA between the peers, the aggregate statistics of phase 1 SA
   communications between the peers and the aggregate statistics of all
   other phase 2 SAs created by the phase 1 SA.  These statistics are
   kept based on the assumption that information is passed forward when
   SAs are re-keyed. This allows network monitors to determine the total
   amount of protected traffic passed between two IPSec implementations.


4.5 Phase 2 SA Tunnels

   Phase 2 or IPSec tunnels are defined as being made up of an arbitrary
   number of phase 2 or IPsec SAs with the same tunnel parameters. They
   may be transient or permanent.  Functionally, this table is very
   similar to the IP Tunnel MIB, however the definition of IPSec SA-
   based tunnels are not defined the same as the tunnels in that MIB.

   Phase 2 tunnels are uniquely identified by the IP addresses (which
   may be single IP addresses, ranges or subnets) at each end, the port
   number at each end and the protocol, as defined in [IPDOI]. Note that
   the protocol and port numbers may be wildcards.

   Further, phase 2 tunnels must be considered different if the services
   they provide changes. In other words, if an SA is created that
   provide compression and ESP is created for the above parameters where
   previous SAs had only ESP, the new SA MUST be considered part of a
   different virtual tunnel than the previous SA.

   Individual phase 2 SAs are presented in another table. Each row of
   the IPSec tunnel table contains configuration information related to
   phase 2 SAs and aggregate statistics related to all of those SAs. It
   does not contain information about specific phase 2 SAs.

   Each row in the table has a value which is an index to the row of
   phase 1 SAs that created it if the phase 2 SA is not a static SA.

   If the tunnel is configured as permanent, its status can be
   determined by the number of phase 2 SAs currently active with it. If
   that number is zero, then the tunnel must be considered down. If that
   number greater than 0, then the tunnel is considered up.


IPSec Working Group                                            [Page 11]


Internet Draft           IPSec Monitoring MIB               October 1998


4.6 Phase 2 SAs

   Individual phase 2 SAs appear in a third table. This table contains
   only the statistics for the individual SA and a value which is an
   index into the phase 2 SA tunnel table. This means that each entry in
   this table is information and statistics for the individual SAs in
   the system that are unique to each SA. Since many SAs may share the
   selectors, these are found in the IPSec tunnel table entry referenced
   by each SA.

   Bundled SAs are supported by having separate objects for each of ESP,
   AH and IPCOMP, under the assumption that no implementation will use
   any of those protocols more than once in the same SA bundle. While no
   particular order of application of the three services is specified,
   it is expected that IPCOMP will always be applied first if used and
   AH will always be applied last if used. Further, the expiration
   parameters specified refer to the minimum value of each security
   service if there is more than one in the bundle.


4.7 Asymmetric Use

   This MIB is defined assuming symmetric use of SAs. That is to say
   that it assumes that an inbound SA is always set up with a
   corresponding outbound SA that provides the same security service.

   In cases where this MIB is required for asymmetric use, the
   corresponding objects that describe the unused direction may be set
   to the equivalent of the unknown or zero state.


4.8 IPSec MIB Traps

   Traps are provided to let system administrators know about the
   creation and deletion of SAs, errors related to the creation of SAs
   and operational errors that may indicate the presence of attacks on
   the system.

   Specifically, the following traps are provided:

     IKE virtual tunnel up (the first IKE SA between two peers has come
       up)
     IKE virtual tunnel down (the IKE SA supporting a virtual tunnel was
       taken down, and no attempt to keep the tunnel up is happening;
       usually administrative)
     IKE SA Negotiation Failure (an attempt to negotiate a phase 1 SA
       failed)



IPSec Working Group                                            [Page 12]


Internet Draft           IPSec Monitoring MIB               October 1998


     Invalid Cookie Problem (OAKLEY packets with invalid cookies were
       detected; should send one trap for each peer, not one trap for
       each packet)
     IPSec SA Tunnel Start (the first IPSec SA for a set of selectors
       has come up)
     IPSec SA Tunnel End (the last IPSec SA for a set of selectors has
       gone down and no attempt at re-keying is being done; usually
       administrative; not sent if phase 1 tunnel is going down as
       well)
     IPSec SA Negotiation Failure (an attempt to negotiate an IPSec SA
       failed)
     IPSec SA Authentication Failure (an IPSec packet with a bad hash
       was received; should send one trap per tunnel, not per packet)
     IPSec SA Replay Failure (an IPSec packet with bad sequence number
       was received; should send one trap per tunnel, not per packet)
     Invalid SPI Problem (ESP, AH or IPCOMP packets with unknown SPIs
       were detected; should send one trap for each SPI, not one trap
       for each packet)
     IPSec SA Policy Failure (a packet was received in a tunnel that
       should not have been sent in a tunnel; should send one trap per
       tunnel, not per packet)


4.9 IPSec Device MIB

   This MIB carries statistics global to the IPSec device.

   Statistics included are error statistics, overall statistics
   associated with SAs, permanent tunnels and overall statistics
   associated with transient tunnels.

   Error statistics:

     The total number of packets received with unknown SPIs (or CPIs).
     The total number of general IKE protocol errors that occurred,
       including packets received with invalid cookies.
     The total number of packets received with authentication errors.
     The total number of packets received with replay errors.
     The total number of packets received with policy errors.

   SA statistics:

     The total number of phase 1 SAs established since boot time.
     The total number of phase 2 SAs established since boot time.






IPSec Working Group                                            [Page 13]


Internet Draft           IPSec Monitoring MIB               October 1998


   Permanent tunnel statistics:

     The current total number of permanent IKE tunnels.
     The current total number of permanent IPSec tunnels.

   Transient tunnel statistics:

     The total number of transient IKE tunnels established since boot
       time. (Includes the next value.)
     The current number of transient IKE tunnels established since boot
       time.
     The total number of transient IPSec tunnels established since boot
       time. (Includes the next value.)
     The current number of transient IPSec tunnels established since
       boot time.
     The total number of inbound packets carried on transient IPSec
       tunnels since boot time.
     The total number of outbound packets carried on transient IPSec
       tunnels since boot time.
     The total amount of inbound traffic carried on transient IPSec
       tunnels since boot time.
     The total amount of outbound traffic carried on transient IPSec
       tunnels since boot time.

   More system wide statistics on transient tunnels is provided since
   they disappear from the tables when they terminate, and aggregate
   traffic statistics associated with individual tunnels is lost.


5. MIB Definitions

  IPSEC-MIB DEFINITIONS ::= BEGIN

      IMPORTS
          MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64,
          Integer32, mib-2, IpAddress              FROM SNMPv2-SMI
          DateAndTime, TruthValue                  FROM SNMPv2-TC;

      ipsecMIB MODULE-IDENTITY
          LAST-UPDATED "????"
          ORGANIZATION "IETF IPSec Working Group"
          CONTACT-INFO
                  "   Tim Jenkins
                      TimeStep Corporation
                      362 Terry Fox Drive
                      Kanata, ON  K0A 2H0
                      Canada



IPSec Working Group                                            [Page 14]


Internet Draft           IPSec Monitoring MIB               October 1998


                      613-599-3610
                      tjenkins@timestep.com"

          DESCRIPTION
                  "The MIB module to describe generic IPSec objects
                   and transient and permanent virtual tunnels created
                   by IPSec SAs."
          REVISION      "????"
          DESCRIPTION
                  "Initial revision."
          ::= { mib-2 ?? }


      ipsecMIBObjects OBJECT IDENTIFIER ::= { ipsecMIB 1 }

      ipsec      OBJECT IDENTIFIER ::= { ipsecMIBObjects 1 }




   -- the IPSec IKE MIB-Group
   --
   -- a collection of objects providing information about
   -- IPSec's IKE SAs and the virtual phase 1 SA tunnels


   ipsecIkeSaTable OBJECT-TYPE
       SYNTAX     SEQUENCE OF IpsecIkeSaEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The (conceptual) table containing information on IPSec's
               IKE SAs."
       ::= { ipsec 1 }

   ipsecIkeSaEntry OBJECT-TYPE
       SYNTAX     IpsecIkeSaEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "An entry (conceptual row) containing the information on
               a particular IKE SA."
       INDEX      { ipsecIkeSaIndex }
       ::= { ipsecIkeSaTable 1 }

   IpsecIkeSaEntry ::= SEQUENCE {
      ipsecIkeSaIndex                  Integer32,



IPSec Working Group                                            [Page 15]


Internet Draft           IPSec Monitoring MIB               October 1998


   -- peer information
      ipsecIkeSaPeerIpAddress          IpAddress,
      ipsecIkeSaPeerPortNumber         INTEGER,
      ipsecIkeSaAuthMethod             Integer32,
      ipsecIkeSaPeerIdType             Integer32,
      ipsecIkeSaPeerId                 OCTET STRING,
      ipsecIkeSaPeerCertSerialNum      OCTET STRING,
      ipsecIkeSaPeerCertIssuer         OCTET STRING,

   -- virtual link status
      ipsecIkeSaType                   INTEGER,
      ipsecIkeSaStatus                 INTEGER,

   -- security algorithm information
      ipsecIkeSaEncAlg                 INTEGER,
      ipsecIkeSaEncLeyLength           Integer32,
      ipsecIkeSaHashAlg                Integer32,
      ipsecIkeSaDifHelGroupDesc        Integer32,
      ipsecIkeSaDifHelGroupType        Integer32,
      ipsecIkeSaDifHelFieldSize        Integer32,
      ipsecIkeSaPRF                    Integer32,
      ipsecIkeSaPFS                    TruthValue,

   -- identifier information
      ipsecIkeSaInitiatorCookie        OCTET STRING,
      ipsecIkeSaResponderCookie        OCTET STRING,

   -- expiration limits, current SA
      ipsecIkeSaTimeStart              DateAndTime,
      ipsecIkeSaTimeLimit              Gauge32,    -- in seconds
      ipsecIkeSaTrafficLimit           Gauge32,    -- in kbytes

   -- current SA's operating statistics
      ipsecIkeSaInboundTraffic         Counter64,  -- in bytes
      ipsecIkeSaOutboundTraffic        Counter64,  -- in bytes
      ipsecIkeSaInboundPackets         Counter32,
      ipsecIkeSaOutboundPackets        Counter32,

   -- aggregate statistics (all SAs)
      ipsecIkeSaTotalSaNum             Counter32,
      ipsecIkeSaFirstTimeStart         DateAndTime,
      ipsecIkeSaTotalInboundTraffic    Counter64,  -- in bytes
      ipsecIkeSaTotalOutboundTraffic   Counter64,  -- in bytes
      ipsecIkeSaTotalInboundPackets    Counter32,
      ipsecIkeSaTotalOutboundPackets   Counter32,

   -- aggregate error statistics
      ipsecIkeSaDecryptErrors          Counter32,


IPSec Working Group                                            [Page 16]


Internet Draft           IPSec Monitoring MIB               October 1998


      ipsecIkeSaHashErrors             Counter32,
      ipsecIkeSaOtherReceiveErrors     Counter32,
      ipsecIkeSaSendErrors             Counter32,

   -- IPSec SA (Phase 2) statistics (aggregate)
      ipsecIkeSaIpsecInboundTraffic    Counter64,
      ipsecIkeSaIpsecOutboundTraffic   Counter64,
      ipsecIkeSaIpsecInboundPackets    Counter32,
      ipsecIkeSaIpsecOutboundPackets   Counter32,

   -- IPSec SA (Phase 2) error statistics (aggregate)
      ipsecIkeSaIpsecDecryptErrors     Counter32,
      ipsecIkeSaIpsecAuthErrors        Counter32,
      ipsecIkeSaIpsecReplayErrors      Counter32,
      ipsecIkeSaIpsecOtherReceiveErrors  Counter32,
      ipsecIkeSaIpsecSendErrors        Counter32

   }

   ipsecIkeSaIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value, greater than zero, for each tunnel
               interface.  It is recommended that values are assigned
               contiguously starting from 1.

               The value for each tunnel interface must remain constant
               at least from one re-initialization of entity's network
               management system to the next re-initialization.

               Further, the value for tunnel interfaces that are marked
               as permanent must remain constand across all re-
               initializations of the network management system."
       ::= { ipsecIkeSaEntry 1 }

   ipsecIkeSaPeerIpAddress OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The IP address of the peer that this SA was negotiated
               with, or 0 if unknown."
       ::= { ipsecIkeSaEntry 2 }

   ipsecIkeSaPeerPortNumber OBJECT-TYPE
       SYNTAX      INTEGER


IPSec Working Group                                            [Page 17]


Internet Draft           IPSec Monitoring MIB               October 1998


       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The port number of the peer that this SA was negotiated
               with, or 0 if the default ISAKMP port number (500)."
       ::= { ipsecIkeSaEntry 3 }

  ipsecIkeSaAuthMethod OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The authentication method used to authenticate the
               peers.

               Note that this does not include the specific method of
               authentication if extended authenticated is used.

               Specific values are used as described in the ISAKMP Class
               Values of Authentication Method from Appendix A of
               [IKE]."
       ::= { ipsecIkeSaEntry 4 }

   ipsecIkeSaPeerIdType OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The type of ID used by the peer.

               Specific values are used as described in Section 4.6.2.1
               of [IPDOI]."
       ::= { ipsecIkeSaEntry 5 }

   ipsecIkeSaPeerId OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (0..511))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The ID of the peer this SA was negotiated with.

               The length may require truncation under some conditions."
       ::= { ipsecIkeSaEntry 6 }

   ipsecIkeSaPeerCertSerialNum OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (0..64))
       MAX-ACCESS  read-only
       STATUS      current


IPSec Working Group                                            [Page 18]


Internet Draft           IPSec Monitoring MIB               October 1998


       DESCRIPTION

               "The serial number of the certificate of the peer this SA
               was negotiated with.

               This object has no meaning if a certificate was not used
               in authenticating the peer."
       ::= { ipsecIkeSaEntry 7 }

   ipsecIkeSaPeerCertIssuer OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (0..511))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The serial number of the certificate of the peer this SA
               was negotiated with.

               This object has no meaning if a certificate was not used
               in authenticating the peer."
       ::= { ipsecIkeSaEntry 8 }

   ipsecIkeSaType OBJECT-TYPE
       SYNTAX      INTEGER { transient(1), permanent(2) }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The type of virtual tunnel represented by this row.

               A transient link will disappear from the table when
               the SAs needed for it cannot be established. A
               permanent link will shows its status in the
               ipsecIkeSaStatus object."
       ::= { ipsecIkeSaEntry 9 }

   ipsecIkeSaStatus OBJECT-TYPE
       SYNTAX      INTEGER
                   { neverTried(0), linkUp(1), linkDown(2) }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The status of the virtual tunnel represented by this
               row, if the tunnel is configured as permanent.

               'neverTried' means that no attempt to set-up the link
               has been done. 'linkUp' means that the link is up and
               operating normally. 'linkDown' means that the link was
               up, but has gone down."
       ::= { ipsecIkeSaEntry 10 }


IPSec Working Group                                            [Page 19]


Internet Draft           IPSec Monitoring MIB               October 1998



   ipsecIkeSaEncAlg OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the encryption algorithm
               applied to traffic carried by this SA or 0 if there
               is no encryption applied.

               Specific values are used as described in the ISAKMP
               Class Values of Encryption Algorithms from Appendix A
               of [IKE]."
       ::= { ipsecIkeSaEntry 11 }

   ipsecIkeSaEncLeyLength OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The length of the encryption key in bits used for
               algorithm specified in the ipsecIkeSaEncAlg object or 0
               if the key length is implicit in the specified
               algorithm or there is no encryption specified."
       ::= { ipsecIkeSaEntry 12 }

   ipsecIkeSaHashAlg OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the hash algorithm applied
               to traffic carried by this SA or 0 if there is no
               encryption applied.

               Specific values are used as described in the ISAKMP Class
               Values of Hash Algorithms from Appendix A of [IKE]."
       ::= { ipsecIkeSaEntry 13 }

  ipsecIkeSaDifHelGroupDesc OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the Diffie-Hellman group
               description used or 0 if the group is unknown.




IPSec Working Group                                            [Page 20]


Internet Draft           IPSec Monitoring MIB               October 1998


               Specific values are used as described in the ISAKMP Class
               Values of Group Description from Appendix A of [IKE]."
       ::= { ipsecIkeSaEntry 14 }

   ipsecIkeSaDifHelGroupType OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the Diffie-Hellman group
               type used or 0 if the group is unknown.

               Specific values are used as described in the ISAKMP Class
               Values of Group Type from Appendix A of [IKE]."
       ::= { ipsecIkeSaEntry 15 }

   ipsecIkeSaDifHelFieldSize OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The field size, in bits, of a Diffie-Hellman group."
       ::= { ipsecIkeSaEntry 16 }

   ipsecIkeSaPRF OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The pseudo-random functions used, or 0 if not used or if
               unknown.

               Specific values are used as described in the ISAKMP Class
               Values of PRF from Appendix A of [IKE]."
       ::= { ipsecIkeSaEntry 17 }

   ipsecIkeSaPFS OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A value that indicates that perfect forward secrecy is
               used for all IPSec SAs created by this IKE SA."
       ::= { ipsecIkeSaEntry 18 }

   ipsecIkeSaInitiatorCookie OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (16))
       MAX-ACCESS  read-only


IPSec Working Group                                            [Page 21]


Internet Draft           IPSec Monitoring MIB               October 1998


       STATUS      current
       DESCRIPTION
               "The value of the cookie used by the initiator for the
               current phase 1 SA."
       ::= { ipsecIkeSaEntry 19 }

   ipsecIkeSaResponderCookie OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE (16))
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the cookie used by the responder for the
               current phase 1 SA."
       ::= { ipsecIkeSaEntry 20 }

   ipsecIkeSaTimeStart OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The date and time that the current SA within the link
               was set up.

               It is not the date and time that the virtual tunnel was
               set up."
       ::= { ipsecIkeSaEntry 21 }

   ipsecIkeSaTimeLimit OBJECT-TYPE
       SYNTAX      Gauge32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The maximum lifetime in seconds of the current SA
               supporting the virtual tunnel, or 0 if there is no time
               constraint on its expiration."
       ::= { ipsecIkeSaEntry 22 }

   ipsecIkeSaTrafficLimit OBJECT-TYPE
       SYNTAX      Gauge32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The maximum traffic in 1024-byte blocks that the current
               SA supporting the virtual tunnel is allowed to support,
               or 0 if there is no traffic constraint on its
               expiration."
       ::= { ipsecIkeSaEntry 23 }



IPSec Working Group                                            [Page 22]


Internet Draft           IPSec Monitoring MIB               October 1998


   ipsecIkeSaInboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The amount traffic measured in bytes handled in the
               current SA in the inbound direction. "
       ::= { ipsecIkeSaEntry 24 }

   ipsecIkeSaOutboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The amount traffic measured in bytes handled in the
               current SA in the outbound direction. "
       ::= { ipsecIkeSaEntry 25 }

   ipsecIkeSaInboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of packets handled in the current SA in the
               inbound direction. "
       ::= { ipsecIkeSaEntry 26 }

   ipsecIkeSaOutboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of packets handled in the current SA in the
               outbound direction. "
       ::= { ipsecIkeSaEntry 27 }

   ipsecIkeSaTotalSaNum OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of SAs, including the current SA, that
               have been set up to support this virtual tunnel."
       ::= { ipsecIkeSaEntry 28 }

   ipsecIkeSaFirstTimeStart OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-only


IPSec Working Group                                            [Page 23]


Internet Draft           IPSec Monitoring MIB               October 1998


       STATUS      current
       DESCRIPTION
               "The data and time that this virtual tunnel was
               originally set up.

               It is not the time that the current SA was set up.

               If this is a permanent virtual tunnel, it is reset when
               the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 29 }

   ipsecIkeSaTotalInboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
      DESCRIPTION
               "The total amount of traffic measured in bytes handled in
               the tunnel in the inbound direction. In other words, it
               is the aggregate value of all inbound traffic carried by
               all SAs ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 30 }

   ipsecIkeSaTotalOutboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total amount of traffic measured in bytes handled in
               the tunnel in the outbound direction. In other words, it
               is the aggregate value of all inbound traffic carried by
               all SAs ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 31 }

   ipsecIkeSaTotalInboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of packets handled by the virtual
               tunnel since it became active in the inbound direction.
               In other words, it is the aggregate value of the number
               of inbound packets carried by all SAs ever set up to


IPSec Working Group                                            [Page 24]


Internet Draft           IPSec Monitoring MIB               October 1998


               support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 32 }

   ipsecIkeSaTotalOutboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of packets handled by the virtual
               tunnel since it became active in the outbound direction.
               In other words, it is the aggregate value of the number
               of outbound packets carried by all SAs ever set up to
               support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 33 }

   ipsecIkeSaDecryptErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets to this SA discarded
               due to decryption errors.

               Note that this refers to IKE protocol packets, and not to
               packets carried by SAs set up by the SAs supporting this
               tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 34 }

   ipsecIkeSaHashErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets to this SA discarded
               due to hash errors.

               Note that this refers to IKE protocol packets, and not to
               packets carried by SAs set up by the SAs supporting this
               tunnel.


IPSec Working Group                                            [Page 25]


Internet Draft           IPSec Monitoring MIB               October 1998



               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 35 }

   ipsecIkeSaOtherReceiveErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets to this SA discarded
               for reasons other than bad hashes or decryption errors.
               This may include packets dropped to a lack of receive
               buffer space.

               Note that this refers to IKE protocol packets, and not to
               packets carried by SAs set up by the SAs supporting this
               tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 36 }

   ipsecIkeSaSendErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of outbound packets from this SA
               discarded for any reason. This may include packets
               dropped to a lack of transmit buffer space.

               Note that this refers to IKE protocol packets, and not to
               packets carried by SAs set up by the SAs supporting this
               tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 37 }

   ipsecIkeSaIpsecInboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total amount of inbound traffic measured in bytes
               handled by all IPSec SAs set up by phase 1 SAs supporting
               this tunnel.


IPSec Working Group                                            [Page 26]


Internet Draft           IPSec Monitoring MIB               October 1998



               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 38 }

   ipsecIkeSaIpsecOutboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
      DESCRIPTION
               "The total amount of outbound traffic measured in bytes
               handled by all IPSec SAs set up by phase 1 SAs supporting
               this tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 39 }

   ipsecIkeSaIpsecInboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets handled by all IPSec
               SAs set up by phase 1 SAs supporting this tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 40 }

   ipsecIkeSaIpsecOutboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of outbound packets handled by all
               IPSec SAs set up by phase 1 SAs supporting this tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 41 }

   ipsecIkeSaIpsecDecryptErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION



IPSec Working Group                                            [Page 27]


Internet Draft           IPSec Monitoring MIB               October 1998


               "The total number of inbound packets discarded by all
               IPSec SAs due to decryption errors.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 42 }

   ipsecIkeSaIpsecAuthErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by all
               IPSec SAs due to authentication errors. This includes
               hash failures in IPSec SAs using ESP and AH.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 43 }

   ipsecIkeSaIpsecReplayErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by all
               IPSec SAs due to replay errors.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 44 }

   ipsecIkeSaIpsecOtherReceiveErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by all
               IPSec SAs due to errors other than authentication,
               decryption or replay errors. This may include packets
               dropped due to lack of receive buffers.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 45 }

   ipsecIkeSaIpsecSendErrors OBJECT-TYPE
       SYNTAX      Counter32


IPSec Working Group                                            [Page 28]


Internet Draft           IPSec Monitoring MIB               October 1998


       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of outbound packets discarded by all
               IPSec SAs due to any error. This may include packets
               dropped due to lack of receive buffers.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the tunnel goes to the 'linkUp' state."
       ::= { ipsecIkeSaEntry 46 }


   -- the IPSec Tunnel MIB-Group
   --
   -- a collection of objects providing information about
   -- IPSec SA-based virtual tunnels


   ipsecTunnelTable OBJECT-TYPE
       SYNTAX     SEQUENCE OF IpsecTunnelEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The (conceptual) table containing information on IPSec
               SA-based tunnels."
       ::= { ipsec 2 }

   ipsecTunnelEntry OBJECT-TYPE
       SYNTAX     IpsecTunnelEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "An entry (conceptual row) containing the information on
               a particular configured tunnel."
       INDEX      { ipsecTunnelIndex }
       ::= { ipsecTunnelTable 1 }

   IpsecTunnelEntry ::= SEQUENCE {
      ipsecTunnelIndex      Integer32,
      ipsecTunnelIkeSa      Integer32, -- if not static
      ipsecTunnelType       INTEGER, -- static, transient, permanent

   -- tunnel identifiers
      ipsecTunnelLocalAddressOrStart          IpAddress,
      ipsecTunnelLocalAddressMaskOrEnd        IpAddress,
      ipsecTunnelRemoteAddressOrStart         IpAddress,
      ipsecTunnelRemoteAddressMaskOrEnd       IpAddress,
      ipsecTunnelProtocol                     Integer32,


IPSec Working Group                                            [Page 29]


Internet Draft           IPSec Monitoring MIB               October 1998


      ipsecTunnelLocalPort                    Integer32,
      ipsecTunnelRemotePort                   Integer32,

   -- tunnel security services description
      ipsecTunnelMode                  INTEGER,
      ipsecTunnelEspEncAlg             Integer32,
      ipsecTunnelEspEncLeyLength       Integer32,
      ipsecTunnelEspAuthAlg            Integer32,
      ipsecTunnelAhAuthAlg             Integer32,
      ipsecTunnelCompAlg               Integer32,

   -- aggregate statistics
      ipsecTunnelStartTime             DateAndTime,
      ipsecTunnelCurrentSaNum          Gauge32,
      ipsecTunnelTotalSaNum            Counter32,
      ipsecTunnelTotalInboundTraffic   Counter64,
      ipsecTunnelTotalOutboundTraffic  Counter64,
      ipsecTunnelTotalInboundPackets   Counter32,
      ipsecTunnelTotalOutboundPackets  Counter32,

   -- aggregate error statistics
      ipsecTunnelDecryptErrors         Counter32,
      ipsecTunnelAuthErrors            Counter32,
      ipsecTunnelReplayErrors          Counter32,
      ipsecTunnelPolicyErrors          Counter32,
      ipsecTunnelOtherReceiveErrors    Counter32,
      ipsecTunnelSendErrors            Counter32

   }


   ipsecTunnelIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value, greater than zero, for each tunnel
               interface.  It is recommended that values are assigned
               contiguously starting from 1.

               The value for each tunnel interface must remain constant
               at least from one re-initialization of the entity's
               network management system to the next re-initialization.

               Further, the value for tunnel interfaces that are marked
               as permanent must remain constant across all re-
               initializations of the network management system."
       ::= { ipsecTunnelEntry 1 }


IPSec Working Group                                            [Page 30]


Internet Draft           IPSec Monitoring MIB               October 1998



   ipsecTunnelIkeSa OBJECT-TYPE
       SYNTAX      Integer32 (0..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the index into the IKE SA tunnel table that
               created this tunnel (ipsecIkeSaIndex), or 0 if the tunnel
               is created by a static IPSec SA."
       ::= { ipsecTunnelEntry 2 }

   ipsecTunnelType OBJECT-TYPE
       SYNTAX      INTEGER { static(0), transient(1), permanent(2) }
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The type of the virtual tunnel represented by this row.

               'static' means that the tunnel is supported by a single
               static IPSec SA that was setup by configuration, and not
               by using a key exchange protocol. In this case, the value
               of ipsecTunnelIkeSa must be 0."
       ::= { ipsecTunnelEntry 3 }

   ipsecTunnelLocalAddressOrStart OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The address of or the start address (if an address
               range) of the local endpoint of the tunnel, or 0.0.0.0 if
               unknown or if the SA uses transport mode encapsulation."
       ::= { ipsecTunnelEntry 4 }

   ipsecTunnelLocalAddressMaskOrEnd OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The mask of or the end address (if an address range) of
               the local endpoint of the tunnel, or 0.0.0.0 if unknown
               or if the SA uses transport mode encapsulation."
       ::= { ipsecTunnelEntry 5 }

   ipsecTunnelRemoteAddressOrStart OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current


IPSec Working Group                                            [Page 31]


Internet Draft           IPSec Monitoring MIB               October 1998


       DESCRIPTION
               "The address of or the start address (if an address
               range) of the remote endpoint of the tunnel, or 0.0.0.0
               if unknown or if the SA uses transport mode
               encapsulation."
       ::= { ipsecTunnelEntry 6 }

   ipsecTunnelRemoteAddressMaskOrEnd OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The mask of or the end address (if an address range) of
               the remote endpoint of the tunnel, or 0.0.0.0 if unknown
               or if the SA uses transport mode encapsulation."
       ::= { ipsecTunnelEntry 7 }

   ipsecTunnelProtocol OBJECT-TYPE
       SYNTAX     Integer32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The number of the protocol that this tunnel carries, or
               0 if it carries any protocol."
       ::= { ipsecTunnelEntry 8 }

   ipsecTunnelLocalPort OBJECT-TYPE
       SYNTAX     Integer32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The number of the local port that this tunnel carries,
               or 0 if it carries any port number."
       ::= { ipsecTunnelEntry 9 }

   ipsecTunnelRemotePort OBJECT-TYPE
       SYNTAX     Integer32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
               "The number of the remote port that this tunnel carries,
               or 0 if it carries any port number."
       ::= { ipsecTunnelEntry 10 }

   ipsecTunnelMode OBJECT-TYPE
       SYNTAX     INTEGER { transport(1), tunnel(2) }
       MAX-ACCESS read-only
       STATUS     current


IPSec Working Group                                            [Page 32]


Internet Draft           IPSec Monitoring MIB               October 1998


       DESCRIPTION
               "The type of encapsulation used by this virtual tunnel."
       ::= { ipsecTunnelEntry 11 }

   ipsecTunnelEspEncAlg OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the encryption algorithm
               applied to traffic carried by this SA if it uses ESP or 0
               if there is no encryption applied by ESP or if ESP is not
               used.

               Specific values are taken from section 4.4.4 of [IPDOI]."
       ::= { ipsecTunnelEntry 12 }

   ipsecTunnelEspEncLeyLength OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The length of the encryption key in bits used for the
               algorithm specified in the ipsecTunnelEspEncAlg object,
               or 0 if the key length is implicit in the specified
               algorithm or there is no encryption specified."
       ::= { ipsecTunnelEntry 13 }

   ipsecTunnelEspAuthAlg OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the hash algorithm applied
               to traffic carried by this SA if it uses ESP or 0 if
               there is no authentication applied by ESP or if ESP is
               not used.

               Specific values are taken from the Authentication
               Algorithm attribute values of Section 4.5 of [IPDOI]."
       ::= { ipsecTunnelEntry 14 }

   ipsecTunnelAhAuthAlg OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION



IPSec Working Group                                            [Page 33]


Internet Draft           IPSec Monitoring MIB               October 1998


               "A unique value representing the hash algorithm applied
               to traffic carried by this SA if it uses AH or 0 if AH is
               not used.

               Specific values are taken from Section 4.4.3 of [IPDOI]."
       ::= { ipsecTunnelEntry 15 }

   ipsecTunnelCompAlg OBJECT-TYPE
       SYNTAX      Integer32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value representing the compression algorithm
               applied to traffic carried by this SA if it uses IPCOMP.

               Specific values are taken from Section 4.4.5 of [IPDOI]."
       ::= { ipsecTunnelEntry 16 }

   ipsecTunnelStartTime OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The date and time that this virtual tunnel was set up.

               If this is a permanent virtual tunnel, it is reset when
               the number of current SAs (ipsecTunnelCurrentSaNum)
               changes from 0 to 1."
       ::= { ipsecTunnelEntry 17 }

   ipsecTunnelCurrentSaNum OBJECT-TYPE
       SYNTAX      Gauge32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of current SAs set up to support this virtual
               tunnel.

               If this number is 0, the tunnel must be considered down.
               Also if this number is 0, the tunnel must a permanent
               tunnel, since transient tunnels that are down do not
               appear in the table."
       ::= { ipsecTunnelEntry 18 }

   ipsecTunnelTotalSaNum OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current


IPSec Working Group                                            [Page 34]


Internet Draft           IPSec Monitoring MIB               October 1998


       DESCRIPTION
               "The total number of SAs, including all current SAs, that
               have been set up to support this virtual tunnel."
       ::= { ipsecTunnelEntry 19 }

   ipsecTunnelTotalInboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total amount of traffic measured in bytes handled in
               the tunnel in the inbound direction. In other words, it
               is the aggregate value of all inbound traffic carried by
               all IPSec SAs ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 20 }

   ipsecTunnelTotalOutboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total amount of traffic measured in bytes handled in
               the tunnel in the outbound direction. In other words, it
               is the aggregate value of all inbound traffic carried by
               all IPSec SAs ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 21 }

   ipsecTunnelTotalInboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of packets handled in the tunnel in the
               inbound direction. In other words, it is the aggregate
               value of all inbound packets carried by all IPSec SAs
               ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."


IPSec Working Group                                            [Page 35]


Internet Draft           IPSec Monitoring MIB               October 1998


       ::= { ipsecTunnelEntry 22 }

   ipsecTunnelTotalOutboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of packets handled in the tunnel in the
               outbound direction. In other words, it is the aggregate
               value of all outbound packets carried by all IPSec SAs
               ever set up to support the virtual tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 23 }

   ipsecTunnelDecryptErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by this
               virtual tunnel due to decryption errors in ESP.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 24 }

   ipsecTunnelAuthErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by this
               virtual tunnel due to authentication errors. This
               includes hash failures in IPSec SA bundles using both ESP
               and AH.

               If this is a permanent virtual tunnel, it is not resetto
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 25 }

   ipsecTunnelReplayErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only


IPSec Working Group                                            [Page 36]


Internet Draft           IPSec Monitoring MIB               October 1998


       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by this
               virtual tunnel due to replay errors. This includes replay
               failures in IPSec SA bundles using both ESP and AH.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 26 }

   ipsecTunnelPolicyErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by this
               virtual tunnel due to policy errors. This includes errors
               in all transforms if SA bundles are used.

               Policy errors are due to the detection of a packet that
               was inappropriately sent into this tunnel.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 27 }


   ipsecTunnelOtherReceiveErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The total number of inbound packets discarded by this
               virtual tunnel due to errors other than decryption,
               authentication or replay errors. This may include packets
               dropped due to a lack of receive buffers.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 28 }

   ipsecTunnelSendErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current


IPSec Working Group                                            [Page 37]


Internet Draft           IPSec Monitoring MIB               October 1998


       DESCRIPTION
               "The total number of outbound packets discarded by this
               virtual tunnel due to any error. This may include packets
               dropped due to a lack of transmit buffers.

               If this is a permanent virtual tunnel, it is not reset to
               zero when the number of current SAs
               (ipsecTunnelCurrentSaNum) changes from 0 to 1."
       ::= { ipsecTunnelEntry 29 }


   -- the IPSec SA MIB-Group
   --
   -- a collection of objects providing information about
   -- IPSec SAs


   ipsecSaTable OBJECT-TYPE
       SYNTAX     SEQUENCE OF IpsecSaEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The (conceptual) table containing information on IPSec
               SAs."
       ::= { ipsec 3 }

   ipsecSaEntry OBJECT-TYPE
       SYNTAX     IpsecSaEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "An entry (conceptual row) containing the information on
               a particular IPSec SA."
       INDEX      { ipsecSaIndex }
       ::= { ipsecSaTable 1 }

   IpsecSaEntry ::= SEQUENCE {
      ipsecSaIndex        Integer32,
      ipsecSaTunnel       Integer32,  -- index from ipsecTunnelTable

   -- identification
      ipsecSaInboundEspSpi          INTEGER,
      ipsecSaOutboundEspSpi         INTEGER,
      ipsecSaInboundAhSpi           INTEGER,
      ipsecSaOutboundAhSpi          INTEGER,
      ipsecSaInboundCompCpi         INTEGER,
      ipsecSaOutboundCompCpi        INTEGER,



IPSec Working Group                                            [Page 38]


Internet Draft           IPSec Monitoring MIB               October 1998


   -- expiration limits
      ipsecSaCreationTime           DateAndTime,
      ipsecSaTimeLimit              Gauge32,  -- seconds, 0 if none
      ipsecSaTrafficLimit           Gauge32,  -- bytes, 0 if none

   -- current operating statistics
      ipsecSaInboundTraffic         Counter64,
      ipsecSaOutboundTraffic        Counter64,
      ipsecSaInboundPackets         Counter32,
      ipsecSaOutboundPackets        Counter32,

   -- error statistics
      ipsecSaDecryptErrors          Counter32,
      ipsecSaAuthErrors             Counter32,
      ipsecSaReplayErrors           Counter32,
      ipsecSaOtherReceiveErrors     Counter32,
      ipsecSaSendErrors             Counter32
   }


   ipsecSaIndex OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "A unique value, greater than zero, for each IPSec SA. It
               is recommended that values are assigned contiguously
               starting from 1."
       ::= { ipsecSaEntry 1 }

   ipsecSaTunnel OBJECT-TYPE
       SYNTAX      Integer32 (1..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the index into the IPSec SA tunnel table
               that this SA supports (ipsecTunnelIndex)."
       ::= { ipsecSaEntry 2 }

   ipsecSaInboundEspSpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the SPI for the inbound SA that provides
               the ESP security service, or zero if ESP is not used."
       ::= { ipsecSaEntry 3 }



IPSec Working Group                                            [Page 39]


Internet Draft           IPSec Monitoring MIB               October 1998


   ipsecSaOutboundEspSpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the SPI for the outbound SA that provides
               the ESP security service, or zero if ESP is not used."
       ::= { ipsecSaEntry 4 }

   ipsecSaInboundAhSpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the SPI for the inbound SA that provides
               the AH security service, or zero if AH is not used."
       ::= { ipsecSaEntry 5 }

   ipsecSaOutboundAhSpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the SPI for the outbound SA that provides
               the AH security service, or zero if AH is not used."
       ::= { ipsecSaEntry 6 }

   ipsecSaInboundCompCpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the CPI for the inbound SA that provides IP
               compression, or zero if IPCOMP is not used."
       ::= { ipsecSaEntry 7 }

   ipsecSaOutboundCompCpi OBJECT-TYPE
       SYNTAX      INTEGER
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of the SPI for the outbound SA that provides
               IP compression, or zero if IPCOMP is not used."
       ::= { ipsecSaEntry 8 }

   ipsecSaCreationTime OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-only


IPSec Working Group                                            [Page 40]


Internet Draft           IPSec Monitoring MIB               October 1998


       STATUS      current
       DESCRIPTION
               "The date and time that the current SA was set up."
       ::= { ipsecSaEntry 9 }

   ipsecSaTimeLimit OBJECT-TYPE
       SYNTAX      Gauge32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The maximum lifetime in seconds of the SA, or 0 if there
               is no time constraint on its expiration."
       ::= { ipsecSaEntry 10 }

   ipsecSaTrafficLimit OBJECT-TYPE
       SYNTAX      Gauge32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The maximum traffic in 1024-byte blocks that the SA is
               allowed to support, or 0 if there is no traffic
               constraint on its expiration."
       ::= { ipsecSaEntry 11 }

   ipsecSaInboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The amount traffic measured in bytes handled by the SA
               in the inbound direction."
       ::= { ipsecSaEntry 12 }

   ipsecSaOutboundTraffic OBJECT-TYPE
       SYNTAX      Counter64
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The amount traffic measured in bytes handled by the SA
               in the outbound direction."
       ::= { ipsecSaEntry 13 }

   ipsecSaInboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION



IPSec Working Group                                            [Page 41]


Internet Draft           IPSec Monitoring MIB               October 1998


               "The number of packets handled by the SA in the inbound
               direction."
       ::= { ipsecSaEntry 14 }

   ipsecSaOutboundPackets OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of packets handled by the SA in the outbound
               direction."
       ::= { ipsecSaEntry 15 }

   ipsecSaDecryptErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of inbound packets discarded by the SA due to
               decryption errors."
       ::= { ipsecSaEntry 16 }

   ipsecSaAuthErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of inbound packets discarded by the SA due to
               authentication errors. This includes hash failures in
               both ESP and AH."
       ::= { ipsecSaEntry 17 }

   ipsecSaReplayErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of inbound packets discarded by the SA due to
               replay errors. This includes replay failures both ESP and
               AH."
       ::= { ipsecSaEntry 18 }

   ipsecSaOtherReceiveErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION



IPSec Working Group                                            [Page 42]


Internet Draft           IPSec Monitoring MIB               October 1998


               "The number of inbound packets discarded by the SA due to
               errors other than decryption, authentication or replay
               errors. This may include decompression errors or errors
               due to a lack of receive buffers."
       ::= { ipsecSaEntry 19 }

   ipsecSaSendErrors OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The number of outbound packets discarded by the SA due
               to any error. This may include compression errors or
               errors due to a lack of transmit buffers."
       ::= { ipsecSaEntry 20 }

   END

6. Security Considerations

   This MIB contains readable objects whose values provide information
   related to IPSec virtual tunnels. There are no objects with
   MAX-ACCESS clauses of read-write or read-create.

   While unauthorized access to the readable objects is relatively
   innocuous, unauthorized access to those objects through an insecure
   channel can provide attackers with more information about a system
   than an administrator may desire.


7. Acknowledgements

   Portions of this document's origins are based on the working paper
   "IP Security Management Information Base" by R. Thayer and U.
   Blumenthal.

   Contributions to this document are the result of input from J.
   Walker, S. Kelly and M. Richardson. Significant contribution comes
   from Charles Brooks of GTW Internetworking.

   Additionally, thanks are extended to Gabriella Dinescu for assistance
   in the preparation of the MIB structures.








IPSec Working Group                                            [Page 43]


Internet Draft           IPSec Monitoring MIB               October 1998


8. References

   [IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation
           for ISAKMP", draft-ietf-ipsec-ipsec-doi-10.txt, work in
           progress.

   [SECARCH] Kent, S., Atkinson, R., _Security Architecture for the
           Internet Protocol_, draft-ietf-ipsec-arch-sec-07.txt, work in
           progress.

   [IKE]   Harkins, D., Carrel, D., "The Internet Key Exchange (IKE),"
           draft-ietf-ipsec-isakmp-oakley-08.txt, work in progress.

   [ISAKMP]Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
           "Internet Security Association and Key Management Protocol
           (ISAKMP)," draft-ietf-ipsec-isakmp-10.{ps,txt}, work in
           progress.

   [IPTun] Thaler, D., "IP Tunnel MIB", draft-ietf-ifmib-tunnel-mib-
           02.txt, work in progress.

   [IGMIB] McCloghrie, K., Kastenholz, F., "The Interfaces Group MIB
           using SMIv2", RFC2233

   [1902]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
           "Structure of Management Information for version 2 of the
           Simple Network Management Protocol (SNMPv2)", RFC 1902,
           January 1996.

   [2271]  Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
           for Describing SNMP Management Frameworks", RFC 2271, January
           1998

   [1155]  Rose, M., and K. McCloghrie, "Structure and Identification of
           Management Information for TCP/IP-based Internets", RFC 1155,
           May 1990

   [1212]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC
           1212, March 1991

   [1215]  M. Rose, "A Convention for Defining Traps for use with the
           SNMP", RFC 1215, March 1991

   [1903]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
           S. Waldbusser, "Textual Conventions for Version 2 of the
           Simple Network Management Protocol (SNMPv2)", RFC 1903,
           January 1996.



IPSec Working Group                                            [Page 44]


Internet Draft           IPSec Monitoring MIB               October 1998


   [1904]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
           S. Waldbusser, "Conformance Statements for Version 2 of the
           Simple Network Management Protocol (SNMPv2)", RFC 1904,
           January 1996.

   [1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
           Network Management Protocol", RFC 1157, May 1990.

   [1901]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
           S. Waldbusser, "Introduction to Community-based SNMPv2", RFC
           1901, January 1996.

   [1906]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
           S. Waldbusser, "Transport Mappings for Version 2 of the
           Simple Network Management Protocol (SNMPv2)", RFC 1906,
           January 1996.

   [2272]  Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
           Processing and Dispatching for the Simple Network Management
           Protocol (SNMP)", RFC 2272, January 1998.

   [2274]  Blumenthal, U., and B. Wijnen, "User-based Security Model
           (USM) for version 3 of the Simple Network Management Protocol
           (SNMPv3)", RFC 2274, January 1998.

   [1905]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
           S. Waldbusser, "Protocol Operations for Version 2 of the
           Simple Network Management Protocol (SNMPv2)", RFC 1905,
           January 1996.

   [2273]  Levi, D., Meyer, P., and B. Stewart, MPv3 Applications", RFC
           2273, SNMP Research, Inc., Secure Computing Corporation,
           Cisco Systems, January 1998.

   [2275]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
           Access Control Model (VACM) for the Simple Network Management
           Protocol (SNMP)", RFC 2275, January 1998.













IPSec Working Group                                            [Page 45]


Internet Draft           IPSec Monitoring MIB               October 1998


9. Editor's Address

     Tim Jenkins
     tjenkins@timestep.com
     TimeStep Corporation
     362 Terry Fox Drive
     Kanata, ON
     Canada
     K2K 2P5
     +1 (613) 599-3610


   The IPSec working group can be contacted via the IPSec working
   group's mailing list (ipsec@tis.com) or through its chairs:

     Robert Moskowitz
     rgm@icsa.net
     International Computer Security Association

     Theodore Y. Ts'o
     tytso@MIT.EDU
     Massachusetts Institute of Technology




























IPSec Working Group                                            [Page 46]