[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mib-doctor review of draft-ietf-ipsp-spd-mib




Hi all,


On Berts request I have done a review of the draft-ietf-ipsp-spd-mib-01.txt.
Hereby my comments. (I am subscribe to this list so I do not need
an explicit CC).


- General, it may be subjective, but I do not like the use
of 'we' and 'us' in an RFC. Therefore, I suggest, for example
change "we should do" into "one should do".

- There are also parts of this MIB which use similar ideas as the
packet filtering in the DIFF-SERV MIB. Maybe it is good to make
a check wheter that can be used. I believe that at least some
terms can be used from that MIB. For instance, incoming -> ingress.
Actually, also the draft itself speaks sometimes of inbound
and sometimes of incoming (in particular the FORMAL MIB part).

- Beyond that I believe it would be a good thing first to clean up the
usage of the language. Sometimes, many object descriptions
can be made way more precise.

- Some comments on the objects, need to be repeated for other
simila objects also. These are not explicitly added.

- What is the rational of defining a filter and a subfilter?
Is the subfilter not just another filter.

- I beleive it may help a reader/implementor a lot if the
logical structure is explained at front of the MIB module.
This descrription is currently brief by the size/complexity/
relations of the tables in the MIB module.

(more detailed comments below)

regards,
Harrie


Abstract


This document defines a 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 is of a more general
nature than for IPsec configuration only, such as for configuration
of a firewall. This MIB module is designed with future extensibility
in mind. It is thus possible to externally add other packet filters
and actions to the policy-based packet filtering system defined in
this document.

I am not sure of the usefulnes of 'future extensibility' here. I would also
indicate that it is therefore possible to extends with enterprises specific
managed objects.



1.  Introduction
[snip]
   It is possible to add other packet transforming
   actions to this MIB module if those actions needed to be performed
   conditionally on filtered traffic.

The last part of the sentence sounds odd.


   Companion documents [RFCXXXX], [RFCYYYY] document actions which are
   specific to IPsec and IKE.  No IPsec or IKE specific actions are
   defined within this document.

Add note that RFCXXXX and RFCYYYY must be replaced by the RFC-editor.


3. 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 contents of this document are also
reflected in the "IPsec Configuration Policy Model" (IPCP) [RFC3585].

Is it not opposite?
The "IPsec Configuration Policy Model" is also reflected in this document.


   This MIB module is a task specific derivation of the IPCP for use
   with SNMPv3.

But how does the MIB relate to the previous documents?


   o  Policies, Groups, Conditions, and some levels of Action are
      generically named.  That is we dropped prefixes like "SA", or

'we dropped' -> 'this document drops' What is 'SA'?

      "ipsec".  This is because we feel that packet classification and
      matching of conditions to actions is more general than IPsec and
      could possibly be reused by other packet transforming actions
      which need to conditionally act on packets matching filters.

If this are general packet filters, why not using diff-serv packet filters.

   o  Filters are implemented in a more generic and scalable manner,
      rather than enforcing the condition/filtering pairing and their
      restrictions upon the user.  The MIB module offers a compound
      filter object to provide for greater flexibility when creating
      complex filters.

Implementations hints are fine, but is it really that this document implement things in a 'more generic and scalable manner'. I guess not, since the RFC does not specify implementation specific things and there contradicts.


4. MIB Module Overview


The MIB module is modularized into several different parts: rules, filters, and actions.

Start new paragraph as you do for the other 'parts'.


 The rules section connects endpoints and
   groups of rules together.

The rules section does not do anything. Maybe the objects defined in the section. It is not really clear what a 'rule' is.

The rules section provides endpoint relationships and grouping of the
'rules'.

  This is partially made up of the
   ipspEndpointToGroupTable, ipspGroupContentsTable, and the
   ipspRuleDefinitionTable.

Why partially? In that case this MIB is incomplete.


 Each row of the ipspRuleDefinitionTable
   connects a filter(s) with an action(s).  It 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 do just that to define IPsec and IKE specific
   actions to be used within this SPD configuration MIB.


The filter section of the MIB module is composed of all the different

'of all the' -> ' of the'


types of filters in the Policy Model. It is partially made up of the

Again 'partially'...


   trueFilter, ipspCompoundFilterTable, ipspIpHeaderFilterTable,
   ipspIpOffsetFilterTable, ipspTimeFilterTable, and the
   ipspIpsoHeaderFilterTable.


The action section of the MIB module contains different action types

'contains different' -> 'contains the different'


from the Policy Model. This document contains only the basic actions
needed for firewall processing (accept, drop, log, ...) that an SPD
implementation will need. The companion documents define the IPsec
and IKE specific actions.



4.1 Usage Tutorial



In order to make use of the tables contained in this document, a general understanding of firewall processing must be first understood. The processing of the security policy database involves applying a set of firewall rules to an interface on a device. The given set of rules to apply to any given interface is defined within the ipspEndpointToGroupTable table. This table maps a given interface to a group of rules. The interface itself with in this table is specified using its assigned address. There is also one group of rules per direction (inbound and outbound).

This sounds more like introduction.




4.1.1 Notational conventions


Notes about the following example operations:


1. All of the example operations in the following section make use
of default values for all columns not listed. The operations and
close are the minimal SNMP Varbinds that must be sent.

'operations and close' do sound odd here. Maybe it is they are eplained later, but a read (me) is confused.

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 the that row. It is left as an
exercise for the reader to turn these into real SNMP operations
using real OIDs and real varbinds in a SET PDU. Example:




       rowEntry(index1     = value1,
                index2     = value2)
             = (column1        = column_value1,
                column2        = column_value2)

I am not getting this example. Maybe it is better if you once explain how the excercise for the reader must be done.


   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32,
       mib-2                    FROM SNMPv2-SMI

Add rfc as comment. (also other imports)



spdMIB MODULE-IDENTITY

       DESCRIPTION
        "This MIB module defines configuration objects for managing
         IPsec Security Policy.

Policy -> Policies



Copyright (C) The Internet Society (2003). This version of

We are in the year 2004.


         this MIB module is part of RFC XXXX, see the RFC itself for
         full legal notices."


-- Revision History



REVISION "200401070000Z" -- 7 January 2004 DESCRIPTION "Initial version, published as RFC xxxx." -- RFC-editor assigns xxxx

Hmm, you use here also RFC XXXX. That was also a reference. Change one of them.


spdConfigObjects OBJECT IDENTIFIER ::= { spdMIB 1 } spdNotificationObjects OBJECT IDENTIFIER ::= { spdMIB 2 } spdConformanceObjects OBJECT IDENTIFIER ::= { spdMIB 3 } spdActions OBJECT IDENTIFIER ::= { spdMIB 4 }

In your introduction text I saw there are three parts. For instance, rules and actions, I see actions here, but no rules.

   -- Note: the following subassignments have been used in other MIBs:
   -- IPSEC-IPSECACTION-MIB:
   --   ipsaMIB MODULE-IDENTITY ::= { spdActions 1 }
   -- IPSEC-IKEACTION-MIB:
   --   ipiaMIB MODULE-IDENTITY ::= { spdActions 2 }

Why do you not import them?


   SpdBooleanOperator ::= TEXTUAL-CONVENTION
       STATUS   current
       DESCRIPTION
           "The SpdBooleanOperator operator is used to specify
            whether sub-components in a decision making process are
            ANDed or ORed together to decide if the resulting
            expression is true or false."
       SYNTAX      INTEGER { or(1), and(2) }

How about XOR and NOT/negate? Or not possible to use?


   SpdIPPacketLogging ::= TEXTUAL-CONVENTION
       STATUS   current
       DESCRIPTION
           "SpdIPPacketLogging specifies whether or not an audit
            message should be logged when a packet is passed through an
            SA.

It does not really indicate whether logging i must be done, but more precise how many bytes of the message must be logged. I guess, it would be better to express that.

Beyond that what is an SA??


  A value of '-1' indicates no logging.  A value of '0'
            or greater indicates that logging should be done and how
            many bytes of the beginning of the packet to place in the
            log. Values greater than the size of the packet being
            processed indicate that the entire packet should be sent.


Examples: '-1' no logging '0' log but do not include any of the packet in the log '20' log and include the first 20 bytes of the packet in the log."

The examples roughly duplicate the text before and do not added much.



   spdIncomingPolicyGroupName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(0..32))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object indicates the policy group containing the
            global system policy that is to be applied on incoming
            packets (I.E., arriving at a interface) when a given
            endpoint does not contain a policy definition in the
            spdEndpointToGroupTable.  Its value can be used as an index
            into the spdGroupContentsTable to retrieve a list of
            policies.  A zero length string indicates no system wide
            policy exits and the default policy of 'accept' should be
            executed for incoming packets until one is imposed by
            either this object or by the endpoint processing a given
            packet."
       ::= { spdLocalConfigObjects 1 }


   spdOutgoingPolicyGroupName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(0..32))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "This object indicates the policy group containing the
            global system policy that is to be applied on outgoing
            packets (I.E., leaving an interface) when a given endpoint
            does not contain a policy definition in the
            spdEndpointToGroupTable.  Its value can be used as an index
            into the spdGroupContentsTable to retrieve a list of
            policies.  A zero length string indicates no system wide
            policy exits and the default policy of 'accept' should be

I beleive that the description is close to the InComing, but for outgoing
packets, I do not believe you could use 'accept'.


executed for outgoing packets until one is imposed by either
this object or by the endpoint processing a given packet."
::= { spdLocalConfigObjects 2 }





spdEndpointToGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is used to map policy (groupings) onto an endpoint where traffic is to pass by. Any policy group assigned to an endpoint is then used to control access to the traffic passing by it.


If an endpoint has been configured with a policy group and no contained rule matches the incoming packet, the default action in this case shall be to drop the packet.


If no policy group has been assigned to an endpoint, then the policy group specified by spdSystemPolicyGroupName should be used for the endpoint." ::= { spdConfigObjects 2 }


spdEndpointToGroupEntry OBJECT-TYPE SYNTAX SpdEndpointToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A mapping assigning a policy group to an endpoint." INDEX { spdEndGroupIdentType, spdEndGroupAddress }

Why is the spdEndGroupDirection not part of the index? It looks to me you make a distinction and thus need to be reflected in making configurations also.

::= { spdEndpointToGroupTable 1 }

   spdEndGroupDirection OBJECT-TYPE
       SYNTAX      INTEGER { incoming(1), outgoing(2) }
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The direction of the packet crossing the interface.  As
            packets arrive or leave an interface, the appropriate
            policy is applied according to the direction it is
            traveling: into or out of the device."

The text does like to me partial repeating itself.


::= { spdEndpointToGroupEntry 1 }


spdEndGroupIdentType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Internet Protocol version of the address associated with a given endpoint. All addresses are represented as an array of octets in network byte order. When combined with the spdEndGroupAddress these objects can be used to uniquely identify an endpoint that a set of policy groups should be applied to. Devices supporting IPv4 MUST support the ipv4 value, and devices supporting IPv6 MUST support the ipv6 value.


Values of unknown, ipv4z, ipv6z and dns are not legal values for this object." ::= { spdEndpointToGroupEntry 2 }


spdEndGroupAddress OBJECT-TYPE SYNTAX InetAddress (SIZE (4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of a given endpoint, the format of which is specified by the spdEndGroupIdentType object." ::= { spdEndpointToGroupEntry 3 }



   spdEndGroupName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE(1..32))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The policy group name to apply to this endpoint.  The
            value of the spdEndGroupName object should then be used
            as an index into the spdGroupContentsTable to come up
            with a list of rules that MUST be applied to this
            endpoint."

This text looks to me a duplicating. If the object has a value I would indeed think it must be used. But how can you make sure that these are used in the spdGroupContentsTable. While thinkin of it, why not using the index of this table in the spdGroupTable? Looks easier to me.

::= { spdEndpointToGroupEntry 4 }


            This object may not be set to active until one or more
            active rows exist within the spdGroupContentsTable for
            the group referenced by the spdEndGroupName object."
       ::= { spdEndpointToGroupEntry 7 }

What happens when you do set it active and those rows do not exist.


   spdGroupContentsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SpdGroupContentsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table contains a list of rules and/or subgroups
            contained within a given policy group.

Is this table used for two purposes?


 The entries are
            sorted by the spdGroupContPriority object and MUST be
            executed in order according to this value, starting with
            the lowest value.  Once a group item has been processed,
            the processor MUST stop processing this packet if an action
            was executed as a result of the processing of a given
            group.  Iterating into the next policy group item by
            finding the next largest spdGroupContPriority object shall
            only be done if no actions were run when processing the
            last item for a given packet."
       ::= { spdConfigObjects 3 }


spdGroupContentsEntry OBJECT-TYPE SYNTAX SpdGroupContentsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines a given sub-component within a policy group."

The table does contain a list of rules anr/or subgroups, but the entries do consist of sub-components. On top of that a sub-component is not defined either.

       INDEX   { spdGroupContName, spdGroupContPriority }
       ::= { spdGroupContentsTable 1 }


   spdGroupContPriority OBJECT-TYPE
       SYNTAX      Integer32 (0..65535)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The priority (sequence number) of the sub-component in
            this group."
       ::= { spdGroupContentsEntry 2 }


spdGroupContFilter OBJECT-TYPE SYNTAX VariablePointer

Since below the pointer refers to entries in tables. Is a RowPointer not prefered then?

       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "spdGroupContFilter points to a filter which is evaluated
            to determine whether the sub-component within this group
            should be exercised.

What is considered a sub-component?



If this column is set to a VariablePointer value which references a non-existent row in an otherwise supported table, the inconsistentName exception should be returned. If the table or scalar pointed to by the VariablePointer is not supported at all, then an inconsistentValue exception should be returned."

What should the value be if the variable pointed to is destroyed?


DEFVAL { spdTrueFilterInstance }

Why do you not use a zeroDotZero?



::= { spdGroupContentsEntry 3 }


spdGroupContComponentType OBJECT-TYPE SYNTAX INTEGER { reserved(0), group(1), rule(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the spdGroupContComponentName object is the name of another group defined within the spdGroupContentsTable or is the name of a rule defined within the spdRuleDefinitionTable."

What do the values mean here? I believe group and rule are ok, but reserved?

       DEFVAL { rule }
       ::= { spdGroupContentsEntry 4 }


spdGroupContComponentName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32))

I notice a lot of times that this indicates a group or rule name. Why not making a single TC providing the semantics for such a name.

       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The name of the policy rule or subgroup contained within
            this group, as indicated by the
            spdGroupContComponentType object."
       ::= { spdGroupContentsEntry 5 }


   spdRuleDefDescription OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A user definable string.

'definable' -> 'defined'



spdRuleDefFilter OBJECT-TYPE

DEF-VAL?? It looks to me a simialr object as before.


::= { spdRuleDefinitionEntry 3 }


spdRuleDefFilterNegated OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "spdRuleDefFilterNegated specifies whether the filter referenced by the spdRuleDefFilter object should be negated or not." DEFVAL { false }

What is the rational for the negation, is not better to added the negated rule instead of this mechanism?

::= { spdRuleDefinitionEntry 4 }


spdRuleDefAction OBJECT-TYPE

DEFVAL?



   spdCompFiltDescription OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A user definable string.  You may use this field for
            your administrative tracking purposes."
       DEFVAL { ''H }

Before this was defined as "".



spdTrueFilter OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This scalar indicates a (automatic) true result for a filter. I.e. this is a filter that is always true, useful for adding as a default filter for a default action or a set of actions." ::= { spdStaticFilters 1 }

What does this add in the boolean logic?


spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }


-- -- Policy IPHeader filter definition table --


spdIpHeaderFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF SpdIpHeaderFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of filter definitions to be used within the spdRuleDefinitionTable or the spdSubfilterTable table." ::= { spdConfigObjects 8 }


I believe this is similar as defined in the DIFF-SERV-MIB.
Would it not be better to use those filters. For instance,
also the IPCDN WG could use the same filters for traffic
filtering.


   spdTimeFiltTimeOfDayMaskStart OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Indicates the starting time of day for which this filter
            evaluates to true.  The date portions of the DateAndTime
            TC are ignored for purposes of evaluating this mask and
            only the time specific portions are used."
       DEFVAL { '00000000000000002b0000'H }
       ::= { spdTimeFilterEntry 7 }

I beleive it would be better to make a new Time TC. You add more semantics to a value that you want.

   spdTimeFiltTimeOfDayMaskEnd OBJECT-TYPE
       SYNTAX      DateAndTime
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Indicates the ending time of day for which this filter
            evaluates to true.  The date portions of the DateAndTime
            TC are ignored for purposes of evaluating this mask and
            only the time specific portions are used.  If this
            starting and ending time values indicated by the
            spdTimeFiltTimeOfDayMaskStart and
            spdTimeFiltTimeOfDayMaskEnd objects are equal, the
            filter is expected to be evaluated over the entire 24
            hour period."
       DEFVAL { '00000000000000002b0000'H }
       ::= { spdTimeFilterEntry 8 }

I would earlier follow a schema as in RFC 2445 is used. Mostly a full day starts at, 00:00:00 and ends at 23:59:00

   spdIPInterfaceType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  accessible-for-notify
       STATUS      current
       DESCRIPTION
           "Contains the interface type for the interface that the

The value should represent an interface type, but you use an InetAddressType as syntax. Is this really correct.

            packet which triggered the notification in question is
            passing through."
       ::= { spdNotificationVariables 2 }


spdIPInterfaceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the interface address for the interface that the packet which triggered the notification in question is passing through."

As with the previous object. Does this have any relationship to the interface MIB.

::= { spdNotificationVariables 3 }


spdIPSourceType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Contains the source address type of the packet which triggered the notification in question."

'in question' what does it add.


::= { spdNotificationVariables 4 }


spdPacketDirection OBJECT-TYPE SYNTAX INTEGER { inbound(1), outbound(2) } MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Indicates if the packet whic triggered the action in questions was inbound our outbound." ::= { spdNotificationVariables 8 }

From the previous source/destinations i get the feeling the direction is already fixed. Why this object?



   spdPacketPart OBJECT-TYPE
       SYNTAX      OCTET STRING
       MAX-ACCESS  accessible-for-notify
       STATUS      current
       DESCRIPTION
           "Is the front part of the packet that triggered this
            notification.  The size is determined by the value of
            'SpdIPPacketLogging' or the size of the packet,
            whichever is smaller."
       ::= { spdNotificationVariables 9 }

The value SpdIPPacketLogging is first of all an TEXTUAL-CONVENTION, secondly the SYNTAX is "Integer32 (-1..65535)" and thus may become 65535 and does not fit in the SNMP packet. How will that be handled?


   --
   spdRuleFilterCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities that include
            an IPsec MIB implementation with Endpoint, Rules, and
            filters support."

Maybe it is a good idea to provide also a ReadOnly Compliance statement. I can immagine setups/implementations that do not allow configuration via SNMP. (See for intstance, the DIFF-SERV-MIB.


       MODULE -- This Module
           MANDATORY-GROUPS { spdEndpointGroup,
                              spdGroupContentsGroup,
                              spdRuleDefinitionGroup,
                              spdIPHeaderFilterGroup,
                              spdStaticFilterGroup,
                           spdStaticActionGroup }


GROUP spdIpsecSystemPolicyNameGroup DESCRIPTION "This group is mandatory for IPsec Policy implementations which support a system policy group name."

If mandatory, why not in the MANDATORY-GROUPS? (also others)


           OBJECT      spdEndGroupRowStatus
           SYNTAX      RowStatus {
                   active(1), createAndGo(4), destroy(6)
           }
           DESCRIPTION
               "Support of the values notInService(2), notReady(3),
                and createAndWait(5) is not required."


OBJECT spdEndGroupLastChanged MIN-ACCESS not-accessible DESCRIPTION "This object not required for compliance."

This may be not required for compliance, but it is defined in a MANDATORY-GROUP. I guess you want to change the grouping then.



spdEndpointGroup OBJECT-GROUP OBJECTS { spdEndGroupName, spdEndGroupLastChanged, spdEndGroupStorageType, spdEndGroupRowStatus } STATUS current DESCRIPTION "The IPsec Policy Endpoint Table Group." ::= { spdGroups 1 }

This counts also for the other descriptions, but it does not add any value. I would suggest a more description text of for instance why/what this group of objects are for.



   spdActionNotificationGroup NOTIFICATION-GROUP
       NOTIFICATIONS {
           spdActionNotification,
           spdPacketNotification
       }
       STATUS current
       DESCRIPTION
               "Notifications."

This description adds nothing. It is equal as not having it. WHat kind fo notifications are these?

::= { spdGroups 14 }



END



6. Security Considerations


6.1 Introduction



This document defines a MIB module used to configure IPsec policy
services. Since IPsec provides security services it is important
that the IPsec configuration data be at least as protected as the
IPsec provided security service. There are two main threats you need
to thwart when configuring IPsec devices.



1. Malicious Configuration: only the official administrators should
be allowed to configure a device. In other words,
administrators' identities should be authenticated and their
access rights checked before they are allowed to do device
configuration. The support for SET operations to the IPSP MIB in
a non-secure environment, without proper protection, can have a
negative effect on the security of the network traffic affected
by the IPSP MIB.



2. Disclosure of Configuration: Malicious parties should not be able to read configuration data while the data is in network transit. Any knowledge about a device's IPsec policy configuration could help an unfriendly party compromise that device and/or the network(s) it protects. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP.


SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.



It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).



Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module, is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.



Therefore, when configuring data in the IPSEC-SPD-MIB, you SHOULD use
SNMP version 3. The rest of this discussion assumes the use of
SNMPv3. This is a real strength, because it allows administrators
the ability to load new IPsec configuration on a device and keep the
conversation private and authenticated under the protection of SNMPv3
before any IPsec protections are available. Once initial
establishment of IPsec configuration on a device has been achieved,
it would be possible to set up IPsec SAs to then also provide
security and integrity services to the configuration conversation.
This may seem redundant at first, but will be shown to have a use for
added privacy protection below.



6.2 Protecting against in-authentic access



The current SNMPv3 User Security Model provides for key based user
authentication. Typically, keys are derived from passwords (but are
not required to be), and the keys are then used in HMAC algorithms
(currently MD5 and SHA-1 HMACs are defined) to authenticate all SNMP
data. Each SNMP device keeps a (configured) list of users and keys.
Under SNMPv3 user keys may be updated as often as an administrator
cares to have users enter new passwords. But Perfect Forward Secrecy
for user keys is not yet provided by standards track documents,
although RFC2786 defines an experimental method of doing so.



6.3 Protecting against involuntary disclosure



While sending IPsec configuration data to a PEP, there are a few critical parameters which MUST NOT be observed by third parties.

It would be wise to spell those objects out.


These include IKE Pre-Shared Keys and possibly the private key of a
public/private key pair for use in a PKI. Were either of those
parameters to be known to a third party, they could then impersonate
your device to other IKE peers. Aside from those critical
parameters, policy administrators have an interest in not divulging
any of their policy configuration. Any knowledge about a device's
configuration could help an unfriendly party compromise that device.
SNMPv3 offers privacy security services, but at the time this
document was written, the only standardized encryption algorithm
supported by SNMPv3 is the DES encryption algorithm. Support for
other (stronger) cryptographic algorithms is in the works and may be
done as you read this. Policy administrators SHOULD use a privacy
security service to configure their IPsec policy which is at least as
strong as the desired IPsec policy. E.G., it is unwise to configure
IPsec parameters implementing 3DES algorithms while only protecting
that conversation with single DES.



6.4 Bootstrapping your configuration


Hopefully vendors will not ship new products with a default SNMPv3
user/password pair, but it is possible. Most SNMPv3 distributions
should hopefully require an out-of-band initialization over a trusted
medium, such as a local console connection.

I understand the point, but what should a vendor do?



8.1 Normative References


The normative refences for SNMP based RFC' can be cleaned up I believe in accordance with the new boiler plate. be aware that the MIB modules that are imported still must be references as RFC.


[RFC3585] Jason, J., Rafalow, L. and E. Vyncke, "IPsec Configuration
Policy Information Model", RFC 3585, August 2003.



8.2 Informative References



[RFCXXXX] Baer, M., Charlet, R., Hardaker, W., Story, R. and C. Wang, "IPsec Security Policy IPsec Action MIB", December 2002.


[RFCYYYY] Baer, M., Charlet, R., Hardaker, W., Story, R. and C. Wang, "IPsec Security Policy IKE Action MIB", December 2002.

Add note for RFC editor to replace RFCXXX/YYY. Also you use RFC XXXX for the dradft itself.


[IPPMWP] Lortz, V. and L. Rafalow, "IPsec Policy Model White Paper", November 2000.



Authors' Addresses

I would put the addresses more compact. No need for filling pages.