Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4807

IPsec Security Policy Database Configuration MIB

Pages: 71
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC4807 - Page 1
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.
Top   ToC   RFC4807 - Page 2

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
Top   ToC   RFC4807 - Page 3

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
Top   ToC   RFC4807 - Page 4
   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.
Top   ToC   RFC4807 - Page 5
   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.
Top   ToC   RFC4807 - Page 6

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
Top   ToC   RFC4807 - Page 7

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
Top   ToC   RFC4807 - Page 8
   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)

Next Section