RFC 4807
IPsec Security Policy Database Configuration MIB
Network Working Group M. Baer Request for Comments: 4807 Sparta, Inc. Category: Standards Track R. Charlet Self W. Hardaker Sparta, Inc. R. Story Revelstone Software C. Wang ARO March 2007 IPsec Security Policy Database Configuration MIB Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Internet-Standard Management Framework . . . . . . . . . . 3 4. Relationship to the DMTF Policy Model . . . . . . . . . . . . 3 5. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 4 5.1. Usage Tutorial . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Notational Conventions . . . . . . . . . . . . . . . . 6 5.1.2. Implementing an Example SPD Policy . . . . . . . . . . 7 6. MIB Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 65 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 65 7.2. Protecting against Unauthenticated Access . . . . . . . . 66 7.3. Protecting against Involuntary Disclosure . . . . . . . . 66 7.4. Bootstrapping Your Configuration . . . . . . . . . . . . . 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 69
1. Introduction
This document defines a MIB module for configuration of an IPsec security policy database (SPD). The IPsec model this MIB is designed to configure is based on the "IPsec Configuration Policy Model" (IPCP) [RFC3585]. The IPCP's IPsec model is, in turn, derived from the Distributed Management Task Force's (DMTF) IPsec model (see below) and from the IPsec model specified in RFC 2401 [RFC2401]. Note: RFC 2401 has been updated by RFC 4301 [RFC4301], but this implementation is based on RFC 2401. The policy-based packet filtering and the corresponding execution of actions configured by this MIB is of a more general nature than for IPsec configuration only, such as for configuration of a firewall. It is possible to extend this MIB module and add other packet-transforming actions that are performed conditionally on an interface's network traffic. The IPsec- and IKE-specific actions are as documented in [IPsec-ACTION] and [IKE-ACTION], respectively, and are not documented in this document.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].3. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410] Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].4. Relationship to the DMTF Policy Model
The Distributed Management Task Force (DMTF) has created an object oriented model of IPsec policy information known as the IPsec Policy Model White Paper [IPPMWP]. The "IPsec Configuration Policy Model" (IPCP) [RFC3585] is based, in large part, on the DMTF's IPsec policy model and on RFC 2401 [RFC2401]. The IPCP document describes a model
for configuring IPsec. This MIB module is a task-specific derivation
(i.e., an SMIv2 instantiation) of the IPCP's IPsec configuration
model for use with Simple Network Management Protocol version 3
(SNMPv3).
The high-level areas where this MIB module diverges from the IPCP
model are:
o Policies, Groups, Conditions, and some levels of Actions are
generically named. In other words, IPsec-specific prefixes like
"SA" (Security Association), or "IPsec", are not used. This
naming convention is used because packet classification and the
matching of conditions to actions is more general than IPsec. The
tables in this document can possibly be reused by other packet-
transforming actions, which need to conditionally act on packets
matching filters.
o Filters are implemented in a more generic and scalable manner,
rather than enforcing the condition/filtering pairing of the IPCP
and its restrictions upon the user. This MIB module offers a
compound filter object providing greater flexibility for complex
filters than the IPCP.
5. MIB Module Overview
The MIB module is modularized into several different parts: rules,
filters, and actions.
The rules section associates endpoints and groups of rules, and
consists of the spdEndpointToGroupTable, spdGroupContentsTable, and
the spdRuleDefinitionTable. Each row of the spdRuleDefinitionTable
connects a filter to an action. It should also be noted that by
referencing the spdCompoundFilterTable, the spdRuleDefinitionTable's
filter column can indicate a set of filters to be processed.
Likewise, by referencing the spdCompoundActionTable, the
spdRuleDefinitionTable's action column can indicate multiple actions
to be executed.
This MIB is structured to allow for reuse through the future creation
of extension tables that provide additional filters and/or actions.
In fact, the companion documents to this one ([IPsec-ACTION] and
[IKE-ACTION]) do just that and define IPsec- and IKE-specific actions
to be used within this SPD configuration MIB. Note: it is expected
that, in order to function properly, extension action MIBs may impose
additional limitations on the objects in this MIB and how they can be
used with the extended actions. An extension action may only support
a subset of the configuration options available in this MIB.
The filter section of the MIB module is composed of the different types of filters in the Policy Model. It is made up of the spdTrueFilter, spdCompoundFilterTable, spdSubfiltersTable spdIpHeaderFilterTable, spdIpOffsetFilterTable, spdTimeFilterTable, spdIpsoHeaderFilterTable. The action section of this MIB module contains only the simple static actions required for the firewall processing that an IPsec SPD implementation requires (e.g., accept, drop, log, etc.). The companion documents of this document define the complex actions necessary for IPsec and IKE negotiations. As may have been noticed above, the MIB uses recursion in a similar manner in several different places. In particular, the spdGroupContentsTable, the spdCompoundFilterTable / spdSubfiltersTable combination, and the spdCompoundActionTable / spdSubactionsTable combination can reference themselves. In the case of the spdGroupContentsTable, a row can indicate a rule (i.e., a row in the spdRuleDefinitionTable) or a group (i.e., another set of one or more rows in the spdGroupContentsTable). This way, a group can contain a set of rules and sub-groups. Sub-groups are just other groups defined in the spdGroupContentsTable. There is no inherent MIB limit to the depth of nesting of groups. The spdCompoundFilterTable / spdSubfiltersTable combination and spdCompoundActionTable / spdSubactionsTable combination are designed almost identically, with one being for filters and the other for actions, respectively. The following descriptions for the compound filter tables can be directly applied to the compound action tables. The combination of the tables spdCompoundFilterTable and spdSubfiltersTable allow a user to create a set of filters that can be referenced from any table as a single filter. A row in the spdCompoundFilterTable has the basic configuration information for the compound filter. The index of spdCompoundFilterTable, spdCompFiltname, is also used as a partial index to reference a set of ordered rows in the spdSubfiltersTable. Each row in spdSubfiltersTable points to a row in another filter table. In this way, the set of rows in spdSubFiltersTable with a matching spdCompFiltName, together with the row in spdCompoundFilterTable indexed by spdCompFiltName, create a compound filter. Note that it is possible for a row in the spdSubfiltersTable to point to a row in the spdCompoundFilterTable. This recursion allows the creation of a filter set that includes other filter sets within it. There is no inherent MIB limit to the nesting of compound filters within compound filters.
5.1. Usage Tutorial
In order to use the tables contained in this document, a general understanding of firewall processing is helpful. The processing of the security policy database (SPD) involves applying a set of SPD rules to an interface on a device. The given set of rules to apply to any given interface is defined within the spdEndpointToGroupTable table. This table maps a given interface to a group of rules. In this table, the interface itself is specified using its assigned address. There is also one group of rules per direction (ingress and egress).5.1.1. Notational Conventions
Notes about the following example operations: 1. All the example operations in the following section make use of default values for all columns not listed. The operations and column values given in the examples are the minimal SNMP Varbinds that must be sent to create a row. 2. The example operations are formatted such that a row (i.e., the table's Entry object) is operated on by using the indexes to that row and the column values for that row. 3. Below is a generic example of the notation used in the following section's examples of this MIB's usage. This example indicates that the MIB row to be set is the row with the index values of value1 for index1, and value2 for index2. Within this row, column1 is set to column_value1, and column2 is set to column_value2.: rowEntry(index1 = value1, index2 = value2) = (column1 = column_value1, column2 = column_value2) 4. The below is a specific example of the notation used in the following section's examples of this MIB's usage. This example represents the status column of a row in the IP- MIB::ipAddressTable table being set to deprecated. The index values for this row are IPv4 and 192.0.2.1. The example notation would look like the following: ipAddressEntry(ipAddressAddrType = 1, -- ipv4 ipAddressAddr = 0xC0000201 ) -- 192.0.2.1 = (ipAddressStatus = 2) -- deprecated
5.1.2. Implementing an Example SPD Policy
As an example, let us define the following administrative policy: On the network interface with IP address 192.0.2.1, all traffic from host 192.0.2.6 will be dropped and all other traffic will be accepted. This policy is enforced by setting the values in the MIB to do the following: o create a filter for 192.0.2.6 o create a rule that connects the 192.0.2.6 filter to a packet drop action o create a rule that always accepts packets o group these rules together in the proper order so that the 192.0.2.6 drop rule is checked first. o connect this group of rules to the 192.0.2.1 interface The first step to do this is creating the filter for the IPv4 address 192.0.2.6: SpdIpHeaderFilterEntry(spdIpHeadFiltName = "192.0.2.6") = (spdIpHeadFiltType = 0x80, -- sourceAddress spdIpHeadFiltIPVersion = 1, -- IPv4 spdIpHeadFiltSrcAddressBegin = 0xC0000206, -- 192.0.2.6 spdIpHeadFiltSrcAddressEnd = 0xC0000206, -- 192.0.2.6 spdIpHeadFiltRowStatus = 4) -- createAndGo Next, a rule is created to connect the above "192.0.2.6" filter to an action to "drop" the packet, as follows: spdRuleDefinitionEntry(spdRuleDefName = "drop from 192.0.2.6") = (spdRuleDefFilter = spdIpHeadFiltType.9.49.57.50.46.48.46.50.46.54, spdRuleDefAction = spdDropAction.0, spdRuleDefRowStatus = 4) -- createAndGo Next, a rule is created that accepts all packets: spdRuleDefinitionEntry(spdRuleDefName = "accept all") = (spdRuleDefFilter = spdTrueFilter.0, spdRuleDefAction = spdAcceptAction.0, spdRuleDefRowStatus = 4) -- createAndGo
Next, these two rules are grouped together. Rule groups attached to
an interface are processed one row at a time. The rows are processed
from lowest to highest spdGroupContPriority value. Because the row
that references the "accept all" rule should be processed last, it is
given the higher spdGroupContPriority value.
SpdGroupContentsEntry(spdGroupContName = "ingress",
spdGroupContPriority = 65535)
= (spdGroupContComponentName = "accept all",
spdGroupContRowStatus = 4) -- createAndGo
SpdGroupContentsEntry(spdGroupContName = "ingress",
spdGroupContPriority = 1000)
= (spdGroupContComponentName = "drop from 192.0.2.6",
spdGroupContRowStatus = 4) -- createAndGo
Finally, this group of rules is connected to the 192.0.2.1 interface
as follows:
SpdEndpointToGroupEntry(spdEndGroupDirection = 1, -- ingress
spdEndGroupIdentType = 4, -- IPv4
spdEndGroupAddress = 0xC0000001)
= (spdEndGroupName = "ingress",
spdEndGroupRowStatus = 4) -- createAndGo
This completes the necessary steps to implement the policy. Once all
of these rules have been applied, the policy should take effect.
(page 8 continued on part 2)
