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]
