tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4807

 Errata 
Proposed STD
Pages: 71
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~mib

IPsec Security Policy Database Configuration MIB

Part 1 of 3, p. 1 to 8
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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 RFC Part