tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3585

Proposed STD
Pages: 88
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: IPSP

IPsec Configuration Policy Information Model

Part 1 of 4, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                           J. Jason
Request for Comments: 3585                             Intel Corporation
Category: Standards Track                                     L. Rafalow
                                                                     IBM
                                                               E. Vyncke
                                                           Cisco Systems
                                                             August 2003


             IPsec Configuration Policy Information Model

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 Internet Society (2003).  All Rights Reserved.

Abstract

   This document presents an object-oriented information model of IP
   Security (IPsec) policy designed to facilitate agreement about the
   content and semantics of IPsec policy, and enable derivations of
   task-specific representations of IPsec policy such as storage schema,
   distribution representations, and policy specification languages used
   to configure IPsec-enabled endpoints.  The information model
   described in this document models the configuration parameters
   defined by IPSec.  The information model also covers the parameters
   found by the Internet Key Exchange protocol (IKE).  Other key
   exchange protocols could easily be added to the information model by
   a simple extension.  Further extensions can further be added easily
   due to the object-oriented nature of the model.

   This information model is based upon the core policy classes as
   defined in the Policy Core Information Model (PCIM) and in the Policy
   Core Information Model Extensions (PCIMe).

Top       Page 2 
Table of Contents

   1.  Introduction..................................................  3
   2.  UML Conventions...............................................  4
   3.  IPsec Policy Model Inheritance Hierarchy......................  6
   4.  Policy Classes................................................ 11
       4.1.  The Class SARule........................................ 13
       4.2.  The Class IKERule....................................... 17
       4.3.  The Class IPsecRule..................................... 18
       4.4.  The Association Class IPsecPolicyForEndpoint............ 18
       4.5.  The Association Class IPsecPolicyForSystem.............. 19
       4.6.  The Aggregation Class SAConditionInRule................. 19
       4.7.  The Aggregation Class PolicyActionInSARule.............. 20
   5.  Condition and Filter Classes.................................. 22
       5.1.  The Class SACondition................................... 23
       5.2.  The Class IPHeadersFilter............................... 23
       5.3.  The Class CredentialFilterEntry......................... 23
       5.4.  The Class IPSOFilterEntry............................... 25
       5.5.  The Class PeerIDPayloadFilterEntry...................... 26
       5.6.  The Association Class FilterOfSACondition............... 28
       5.7.  The Association Class AcceptCredentialFrom.............. 29
   6.  Action Classes................................................ 30
       6.1.  The Class SAAction...................................... 32
       6.2.  The Class SAStaticAction................................ 33
       6.3.  The Class IPsecBypassAction............................. 34
       6.4.  The Class IPsecDiscardAction............................ 34
       6.5.  The Class IKERejectAction............................... 35
       6.6.  The Class PreconfiguredSAAction......................... 35
       6.7.  The Class PreconfiguredTransportAction.................. 36
       6.8.  The Class PreconfiguredTunnelAction..................... 37
       6.9.  The Class SANegotiationAction........................... 37
       6.10. The Class IKENegotiationAction.......................... 38
       6.11. The Class IPsecAction................................... 39
       6.12. The Class IPsecTransportAction.......................... 41
       6.13. The Class IPsecTunnelAction............................. 42
       6.14. The Class IKEAction..................................... 42
       6.15. The Class PeerGateway................................... 44
       6.16. The Association Class PeerGatewayForTunnel.............. 45
       6.17. The Aggregation Class ContainedProposal................. 46
       6.18. The Association Class HostedPeerGatewayInformation...... 47
       6.19. The Association Class TransformOfPreconfiguredAction.... 48
       6.20  The Association Class PeerGatewayForPreconfiguredTunnel. 49
   7.  Proposal and Transform Classes................................ 50
       7.1.  The Abstract Class SAProposal........................... 50
       7.2.  The Class IKEProposal................................... 51
       7.3.  The Class IPsecProposal................................. 54
       7.4.  The Abstract Class SATransform.......................... 54
       7.5.  The Class AHTransform................................... 56

Top      ToC       Page 3 
       7.6.  The Class ESPTransform.................................. 57
       7.7.  The Class IPCOMPTransform............................... 59
       7.8.  The Association Class SAProposalInSystem................ 60
       7.9.  The Aggregation Class ContainedTransform................ 60
       7.10. The Association Class SATransformInSystem............... 62
   8.  IKE Service and Identity Classes.............................. 63
       8.1.  The Class IKEService.................................... 64
       8.2.  The Class PeerIdentityTable............................. 64
       8.3.  The Class PeerIdentityEntry............................. 65
       8.4.  The Class AutostartIKEConfiguration..................... 66
       8.5.  The Class AutostartIKESetting........................... 67
       8.6.  The Class IKEIdentity................................... 69
       8.7.  The Association Class HostedPeerIdentityTable........... 71
       8.8.  The Aggregation Class PeerIdentityMember................ 71
       8.9.  The Association Class IKEServicePeerGateway............. 72
       8.10. The Association Class IKEServicePeerIdentityTable....... 73
       8.11. The Association Class IKEAutostartSetting............... 73
       8.12. The Aggregation Class AutostartIKESettingContext........ 74
       8.13. The Association Class IKEServiceForEndpoint............. 75
       8.14. The Association Class IKEAutostartConfiguration......... 76
       8.15. The Association Class IKEUsesCredentialManagementService 77
       8.16. The Association Class EndpointHasLocalIKEIdentity....... 77
       8.17. The Association Class CollectionHasLocalIKEIdentity..... 78
       8.18. The Association Class IKEIdentitysCredential............ 79
   9.  Implementation Requirements................................... 79
   10. Security Considerations....................................... 84
   11. Intellectual Property Statement............................... 84
   12. References ................................................... 85
       12.1. Normative References.................................... 85
       12.2. Informative References.................................. 86
   13. Disclaimer.................................................... 86
   14. Acknowledgments............................................... 86
   15. Authors' Addresses............................................ 87
   16. Full Copyright Statement...................................... 88

1. Introduction

   IP security (IPsec) policy may assume a variety of forms as it
   travels from storage, to distribution, to decision points.  At each
   step, it needs to be represented in a way that is convenient for the
   current task.  For example, the policy could exist as, but is not
   limited to:

   o  A Lightweight Directory Access Protocol (LDAP) [LDAP] schema in a
      directory.

   o  An on-the-wire representation over a transport protocol like the
      Common Object Policy Service (COPS) [COPS, COPSPR].

Top      ToC       Page 4 
   o  A text-based policy specification language suitable for editing by
      an administrator.

   o  An Extensible Markup Language (XML) document.

   Each of these task-specific representations should be derived from a
   canonical representation that precisely specifies the content and
   semantics of the IPsec policy.  This document captures this concept
   and introduces a task-independent canonical representation for IPsec
   policies.

   This document focuses mainly on the existing protocols [COMP, ESP,
   AH, DOI, IKE].  The model can easily be extended if needed due to its
   object-oriented nature.

   This document is organized as follows:

   o  Section 2 provides a quick introduction to the Unified Modeling
      Language (UML) graphical notation conventions used in this
      document.

   o  Section 3 provides the inheritance hierarchy that describes where
      the IPsec policy classes fit into the policy class hierarchy
      already defined by the Policy Core Information Model (PCIM) and
      Policy Core Information Model Extensions (PCIMe).

   o  Sections 4 through 8 describe the classes that make up the IPsec
      policy model.

   o  Section 9 presents the implementation requirements for the classes
      in the model (i.e., the MUST/MAY/SHOULD status).

   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 [KEYWORDS].

2. UML Conventions

   For this document, a UML static class diagram was chosen as the
   canonical representation for the IPsec policy model, because UML
   provides a graphical, task-independent way to model systems.  A
   treatise on the graphical notation used in UML is beyond the scope of
   this paper.  However, given the use of ASCII drawing for UML static
   class diagrams, a description of the notational conventions used in
   this document is in order:

Top      ToC       Page 5 
   o  Boxes represent classes, with class names in brackets ([])
      representing an abstract class.

   o  A line that terminates with an arrow (<, >, ^, v) denotes
      inheritance.  The arrow always points to the parent class.
      Inheritance can also be called generalization or specialization
      (depending upon the reference point).  A base class is a
      generalization of a derived class, and a derived class is a
      specialization of a base class.

   o  Associations are used to model a relationship between two classes.
      Classes that share an association are connected using a line.  A
      special kind of association is also used:  an aggregation.  An
      aggregation models a whole-part relationship between two classes.
      Associations, and therefore aggregations, are also modeled as
      classes.

   o  A line that begins with an "o" denotes aggregation.  Aggregation
      denotes containment in which the contained class and the
      containing class have independent lifetimes.

   o  At each end of a line representing an association appears a
      cardinality (i.e., each association has 2 cardinalities).
      Cardinalities indicate the constraints on the number of object
      instances in a set of relationships.  The cardinality on a given
      end of an association indicates the number of different object
      instances of that class that may be associated with a single
      object instance of the class on the other end of the association.
      The cardinality may be:

      -  a range in the form "lower bound..upper bound" indicating the
         minimum and maximum number of objects.

      -  a number that indicates the exact number of objects.

      -  an asterisk indicating any number of objects, including zero.
         An asterisk is shorthand for 0..n.

      -  the letter n indicating from 1 to many.  The letter n is
         shorthand for 1..n.

   o  A class that has an association may have a "w" next to the line
      representing the association.  This is called a weak association
      and is discussed in [PCIM].

   It should be noted that the UML static class diagram presented is a
   conceptual view of IPsec policy designed to aid in understanding.  It
   does not necessarily get translated class for class into another

Top      ToC       Page 6 
   representation.  For example, an LDAP implementation may flatten out
   the representation to fewer classes (because of the inefficiency of
   following references).

3. IPsec Policy Model Inheritance Hierarchy

   Like PCIM and PCIMe, the IPsec Configuration Policy Model derives
   from and uses classes defined in the DMTF [DMTF] Common Information
   Model (CIM).  The following tree represents the inheritance hierarchy
   for the IPsec Policy Model classes and how they fit into PCIM, PCIMe
   and the other DMTF models (see Appendices for descriptions of classes
   that are not being introduced as part of IPsec model).  CIM classes
   that are not used as a superclass to derive new classes, but are used
   only as references, are not included in this inheritance hierarchy,
   but can be found in the appropriate DMTF document:  Core Model
   [CIMCORE], User Model [CIMUSER] or, Network Model [CIMNETWORK].

         ManagedElement (DMTF Core Model)
         |
         +--Collection (DMTF Core Model)
         |  |
         |  +--PeerIdentityTable
         |
         +--ManagedSystemElement (DMTF Core Model)
         |  |
         |  +--LogicalElement (DMTF Core Model)
         |     |
         |     +--FilterEntryBase (DMTF Network Model)
         |     |  |
         |     |  +--CredentialFilterEntry
         |     |  |
         |     |  +--IPHeadersFilter (PCIMe)
         |     |  |
         |     |  +--IPSOFilterEntry
         |     |  |
         |     |  +--PeerIDPayloadFilterEntry
         |     |
         |     +--PeerGateway
         |     |
         |     +--PeerIdentityEntry
         |     |
         |     +--Service (DMTF Core Model)
         |        |
         |        +--IKEService
         |

Top      ToC       Page 7 
         +--OrganizationalEntity (DMTF User Model)
         |  |
         |  +--UserEntity (DMTF User Model)
         |     |
         |     +--UsersAccess (DMTF User Model)
         |        |
         |        +--IKEIdentity
         |
         +--Policy (PCIM)
         |  |
         |  +--PolicyAction (PCIM)
         |  |  |
         |  |  +--CompoundPolicyAction (PCIMe)
         |  |  |
         |  |  +--SAAction
         |  |     |
         |  |     +--SANegotiationAction
         |  |     |  |
         |  |     |  +--IKENegotiationAction
         |  |     |     |
         |  |     |     +--IKEAction
         |  |     |     |
         |  |     |     +--IPsecAction
         |  |     |        |
         |  |     |        +--IPsecTransportAction
         |  |     |        |
         |  |     |        +--IPsecTunnelAction
         |  |     |
         |  |     +--SAStaticAction
         |  |        |
         |  |        +--IKERejectAction
         |  |        |
         |  |        +--IPsecBypassAction
         |  |        |
         |  |        +--IPsecDiscardAction
         |  |        |
         |  |        +--PreconfiguredSAAction
         |  |           |
         |  |           +--PreconfiguredTransportAction
         |  |           |
         |  |           +--PreconfiguredTunnelAction
         |  |
         |  +--PolicyCondition (PCIM)
         |  |  |
         |  |  +--SACondition
         |  |
         |  +--PolicySet (PCIMe)
         |  |  |

Top      ToC       Page 8 
         |  |  +--PolicyGroup (PCIM & PCIMe)
         |  |  |
         |  |  +--PolicyRule (PCIM & PCIMe)
         |  |     |
         |  |     +--SARule
         |  |        |
         |  |        +--IKERule
         |  |        |
         |  |        +--IPsecRule
         |  |
         |  +--SAProposal
         |  |  |
         |  |  +--IKEProposal
         |  |  |
         |  |  +--IPsecProposal
         |  |
         |  +--SATransform
         |     |
         |     +--AHTransform
         |     |
         |     +--ESPTransform
         |     |
         |     +--IPCOMPTransform
         |
         +--Setting (DMTF Core Model)
         |  |
         |  +--SystemSetting (DMTF Core Model)
         |     |
         |     +--AutostartIKESetting
         |
         +--SystemConfiguration (DMTF Core Model)
            |
            +--AutostartIKEConfiguration

   The following tree represents the inheritance hierarchy of the IPsec
   policy model association classes and how they fit into PCIM and the
   other DMTF models (see Appendices for description of association
   classes that are not being introduced as part of IPsec model).

         Dependency (DMTF Core Model)
         |
         +--AcceptCredentialsFrom
         |
         +--ElementAsUser (DMTF User Model)
         |  |
         |  +--EndpointHasLocalIKEIdentity
         |  |
         |  +--CollectionHasLocalIKEIdentity

Top      ToC       Page 9 
         |
         +--FilterOfSACondition
         |
         +--HostedPeerGatewayInformation
         |
         +--HostedPeerIdentityTable
         |
         +--IKEAutostartConfiguration
         |
         +--IKEServiceForEndpoint
         |
         +--IKEServicePeerGateway
         |
         +--IKEServicePeerIdentityTable
         |
         +--IKEUsesCredentialManagementService
         |
         +--IPsecPolicyForEndpoint
         |
         +--IPsecPolicyForSystem
         |
         +--PeerGatewayForPreconfiguredTunnel
         |
         +--PeerGatewayForTunnel
         |
         +--PolicyInSystem (PCIM)
         |  |
         |  +--SAProposalInSystem
         |  |
         |  +--SATransformInSystem
         |
         +--TransformOfPreconfiguredAction
         |
         +--UsersCredential (DMTF User Model)
            |
            +--IKEIdentitysCredential

         ElementSetting (DMTF Core Model)
         |
         +--IKEAutostartSetting

         MemberOfCollection (DMTF Core Model)
         |
         +--PeerIdentityMember

         PolicyComponent (PCIM)
         |

Top      ToC       Page 10 
         +--ContainedProposal
         |
         +--ContainedTransform
         |
         +--PolicyActionStructure (PCIMe)
         |  |
         |  +--PolicyActionInPolicyRule (PCIM & PCIMe)
         |     |
         |     +--PolicyActionInSARule
         |
         +--PolicyConditionStructure (PCIMe)
         |  |
         |  +--PolicyConditionInPolicyRule (PCIM & PCIMe)
         |     |
         |     +--SAConditionInRule
         |
         +--PolicySetComponent (PCIMe)

         SystemSettingContext (DMTF Core Model)
         |
         +--AutostartIKESettingContext

Top      ToC       Page 11 
4. Policy Classes

   The IPsec policy classes represent the set of policies that are
   contained on a system.

                                  +--------------+
                                  | [PolicySet]  |*
                                  |  ([PCIME])   |o--+
                                  +--------------+   |
                                         ^   *|      |(a)
                                         |    +------+
              +--------------------------+
              |                          |
       +-------------+            +--------------+
       | PolicyGroup |0..1        |  PolicyRule  |*
       |  ([PCIM])   |-----+      |  ([PCIM])    |o--+
       +-------------+     |      +--------------+   |(d)
          0..1|            |            ^            |
              |(b)         |            |            |*
             *|            |            | +---------------------------+
   +--------------------+  |(c)         | | PolicyTimePeriodCondition |
   | IPProtocolEndpoint |  |            | |         ([PCIM])          |
   |   ([CIMNETWORK])   |  |            | +---------------------------+
   +--------------------+  |            |
         +------------+    |      *+----------+*
         |   System   |----+    +-o|  SARule  |o-------+
         | ([CIMCORE])|*        |  +----------+        |(f)
         +------------+         |       ^              |
                             (e)|       |              |n
         +-------------+n       |       |        +--------------+
         | SACondition |--------+       |        |[PolicyAction]|
         +-------------+                |        |   ([PCIM])   |
                                        |        +--------------+
                                        |          *|        ^
                                        |           |(g)     |
                                        |           |        +-------+
                                        |          *o        |       |
                                        |  +----------------------+  |
                                        |  | CompoundPolicyAction |  |
                                        |  |       ([PCIME])      |  |
                                        |  +----------------------+  |
                                        |                            |
                              +---------+----+             +---------+
                              |              |             |
                         +---------+   +-----------+   +----------+
                         | IKERule |   | IPsecRule |   | SAAction |
                         +---------+   +-----------+   +----------+

Top      ToC       Page 12 
      (a)  PolicySetComponent ([PCIME])
      (b)  IPsecPolicyForEndpoint
      (c)  IPsecPolicyForSystem
      (d)  PolicyRuleValidityPeriod ([PCIM])
      (e)  SAConditionInRule
      (f)  PolicyActionInSARule
      (g)  PolicyActionInPolicyAction ([PCIME])

   A PolicyGroup represents the set of policies that are used on an
   interface.   This PolicyGroup SHOULD be associated either directly
   with the IPProtocolEndpoint class instance that represents the
   interface (via the IPsecPolicyForEndpoint association) or indirectly
   (via the IPsecPolicyForSystem association) associated with the System
   that hosts the interface.

   The IKE and IPsec rules are used to build or to negotiate the IPsec
   Security Association Database (SADB).  The IPsec rules represent the
   Security Policy Database.  The SADB itself is not modeled by this
   document.

   The IKE and IPsec rules can be described as (also see section 6 about
   actions):

   o  An egress unprotected packet will first be checked against the
      IPsec rules.  If a match is found, the SADB will be checked.  If
      there is no corresponding IPsec SA in the SADB, and if IKE
      negotiation is required by the IPsec rule, the corresponding IKE
      rules will be used.  The negotiated or preconfigured SA will then
      be installed in the SADB.

   o  An ingress unprotected packet will first be checked against the
      IPsec rules.  If a match is found, the SADB will be checked for a
      corresponding IPsec SA.  If there is no corresponding IPsec SA and
      a preconfigured SA exists, this preconfigured SA will be installed
      in the IPsec SADB.  This behavior should only apply to bypass and
      discard actions.

   o  An ingress protected packet will first be checked against the
      IPsec rules.  If a match is found, the SADB will be checked for a
      corresponding IPsec SA.  If there is no corresponding IPsec SA and
      a preconfigured SA exists, this preconfigured SA will be installed
      in the IPsec SADB.

   o  An ingress IKE negotiation packet, which is not part of an
      existing IKE SA, will be checked against the IKE rules.  The
      SACondition for the IKERule will usually be composed of a
      PeerIDPayloadFilterEntry (typically for an aggressive mode IKE

Top      ToC       Page 13 
      negotiation) or an IPHeadersFilter.  The negotiated SA will then
      be installed in the SADB.

   It is expected that when an IKE negotiation is required to be
   initiated by an IPsec rule, the set of IKE rules will be checked.
   The IKE rules check will be based on the outgoing IKE packet using
   IPHeadersFilter entries (typically using the HdrDstAddress property).

4.1. The Class SARule

   The class SARule serves as a base class for IKERule and IPsecRule.
   Even though the class is concrete, it MUST not be instantiated.  It
   defines a common connection point for associations to conditions and
   actions for both types of rules.  Through its derivation from
   PolicyRule, an SARule (and therefore IKERule and IPsecRule) also has
   the PolicyRuleValidityPeriod association.

   Each SARule in a valid PolicyGroup MUST have a unique associated
   priority number in the PolicySetComponent.Priority.  The class
   definition for SARule is as follows:

      NAME         SARule
      DESCRIPTION  A base class for IKERule and IPsecRule.
      DERIVED FROM PolicyRule (see [PCIM] & [PCIME])
      ABSTRACT     FALSE
      PROPERTIES   PolicyRuleName (from PolicyRule)
                   Enabled (from PolicyRule)
                   ConditionListType (from PolicyRule)
                   RuleUsage (from PolicyRule)
                   Mandatory (from PolicyRule)
                   SequencedActions (from PolicyRule)
                   ExecutionStrategy (from PolicyRule)
                   PolicyRoles (from PolicySet)
                   PolicyDecisionStrategy (from PolicySet)
                   LimitNegotiation

4.1.1. The Properties PolicyRuleName, Enabled, ConditionListType,
       RuleUsage, Mandatory, SequencedActions, PolicyRoles, and
       PolicyDecisionStrategy

   For a description of these properties, see [PCIM] and [PCIME].

   In SARule subclass instances:

   -  if the property Mandatory exists, it MUST be set to "true".

   -  if the property SequencedActions exists, it MUST be set to
      "mandatory".

Top      ToC       Page 14 
   -  the property PolicyRoles is not used in the device-level model.

   -  if the property PolicyDecisionStrategy exists, it must be set to
      "FirstMatching".

4.1.2. The Property ExecutionStrategy

   The ExecutionStrategy properties in the PolicyRule subclasses (and in
   the CompoundPolicyAction class) determine the behavior of the
   contained actions.  It defines the strategy to be used in executing
   the sequenced actions aggregated by a rule or a compound action.  In
   the case of actions within a rule, the PolicyActionInSARule
   aggregation is used to collect the actions into an ordered set; in
   the case of a compound action, the PolicyActionInPolicyAction
   aggregation is used to collect the actions into an ordered subset.

   There are three execution strategies: do until success, do all, and
   do until failure.

   "Do Until Success" causes the execution of actions according to the
   ActionOrder property in the aggregation instances until a successful
   execution of a single action.  These actions may be evaluated to
   determine if they are appropriate to execute rather than blindly
   trying each of the actions until one succeeds.  For an initiator,
   they are tried in the ActionOrder until the list is exhausted or one
   completes successfully.  For example, an IKE initiator may have
   several IKEActions for the same SACondition.  The initiator will try
   all IKEActions in the order defined by ActionOrder.  I.e., it will
   possibly try several phase 1 negotiations with different modes (main
   mode then aggressive mode) and/or with multiple IKE peers.  For a
   responder, when there is more than one action in the rule with "do
   until success" condition clause, this provides alternative actions
   depending on the received proposals.  For example, the same IKERule
   may be used to handle aggressive mode and main mode negotiations with
   different actions.  The responder uses the first appropriate action
   in the list of actions.

   "Do All" causes the execution of all the actions in the aggregated
   set according to their defined order.  The execution continues
   regardless of failures.

   "Do Until Failure" causes the execution of all actions according to a
   predefined order until the first failure in execution of an action
   instance.  Please note that if all actions are successful, then the
   aggregated result is a failure.  This execution strategy is inherited
   from [PCIME] and is not expected to be of any use for IPsec
   configuration.

Top      ToC       Page 15 
   For example, in a nested SAs case, the actions of an initiator's rule
   might be structured as:

   IPsecRule.ExecutionStrategy='Do All'
   |
   +---1--- IPsecTunnelAction    // set up SA from host to gateway
   |
   +---2--- IPsecTransportAction // set up SA from host through
                                 // tunnel to remote host

   Another example, showing a rule with fallback actions might be
   structured as:

   IPsecRule.ExecutionStrategy='Do Until Success'
   |
   +---6--- IPsecTransportAction // negotiate SA with peer
   |
   +---9--- IPsecBypassAction    // but if you must, allow in the clear

   The CompoundPolicyAction class (See [PCIME]) may be used in
   constructing the actions of IKE and IPsec rules when those rules
   specify both multiple actions and fallback actions.  The
   ExecutionStrategy property in CompoundPolicyAction is used in
   conjunction with that in the PolicyRule.

   For example, in nesting SAs with a fallback security gateway, the
   actions of a rule might be structured as:

   IPsecRule.ExecutionStrategy='Do All'
   |
   +---1--- CompoundPolicyAction.ExecutionStrategy='Do Until Success'
   |        |
   |        +---1--- IPsecTunnelAction  // set up SA from host to
   |        |                           // gateway1
   |        |
   |        +---2--- IPsecTunnelAction  // or set up SA to gateway2
   |
   +---2--- IPsecTransportAction        // then set up SA from host
                                        // through tunnel to remote
                                        // host

   In the case of "Do All", a couple of actions can be executed
   successfully before a subsequent action fails.  In this case, some
   IKE or IPsec actions may have resulted in SAs creation.  Even if the
   net effect of the aggregated actions is failure, those created SAs
   MAY be kept or MAY be deleted.

Top      ToC       Page 16 
   In the case of "Do All", the IPsec selectors to be used during IPsec
   SA negotiation are:

   -  for the last IPsecAction of the aggregation (i.e., usually the
      innermost IPsec SA): this is the combination of the
      IPHeadersFilter class and of the Granularity property of the
      IPsecAction.

   -  for all other IPsecActions of the aggregation: the selector is the
      source IP address which is the local IP address, and the
      destination IP address is the PeerGateway IP address of the
      following IPsecAction of the "Do All" aggregation.  NB: the
      granularity is IP address to IP address.

   If the above behavior is not desirable, the alternative is to define
   several SARules, one for each IPsec SA to be built.  This will allow
   the definition of specific IPsec selectors for all IPsecActions.

4.1.3  The Property LimitNegotiation

   The property LimitNegotiation is used as part of processing either an
   IKE or an IPsec rule.

   Before proceeding with a phase 1 negotiation, this property is
   checked to determine whether the negotiation role of the rule matches
   that defined for the negotiation being undertaken (e.g., Initiator,
   Responder, or Both).  If this check fails (e.g., the current role is
   IKE responder, while the rule specifies IKE initiator), then the IKE
   negotiation is stopped.  Note that this only applies to new IKE phase
   1 negotiations and has no effect on either renegotiation or refresh
   operations with peers for which an established SA already exists.

   Before proceeding with a phase 2 negotiation, the LimitNegotiation
   property of the IPsecRule is first checked to determine if the
   negotiation role indicated for the rule matches that of the current
   negotiation (Initiator, Responder, or Either).  Note that this limit
   applies only to new phase 2 negotiations.  It is ignored when an
   attempt is made to refresh an expiring SA (either side can initiate a
   refresh operation).  The IKE system can determine that the
   negotiation is a refresh operation by checking to see if the selector
   information matches that of an existing SA.  If LimitNegotiation does
   not match and the selector corresponds to a new SA, the negotiation
   is stopped.

Top      ToC       Page 17 
   The property is defined as follows:

      NAME         LimitNegotiation
      DESCRIPTION  Limits the role to be undertaken during negotiation.
      SYNTAX       unsigned 16-bit integer
      VALUE        1 - initiator-only
                   2 - responder-only
                   3 - both

4.2. The Class IKERule

   The class IKERule associates Conditions and Actions for IKE phase 1
   negotiations.  The class definition for IKERule is as follows:

      NAME         IKERule
      DESCRIPTION  Associates Conditions and Actions for IKE phase 1
                   negotiations.
      DERIVED FROM SARule
      ABSTRACT     FALSE
      PROPERTIES   same as SARule, plus
                   IdentityContexts

4.2.1. The Property IdentityContexts

   The IKE service of a security endpoint may have multiple identities
   for use in different situations.  The combination of the interface
   (represented by the IPProtocolEndpoint or by a collection of
   IPProtocolEndpoints), the identity type (as specified in the
   IKEAction), and the IdentityContexts specifies a unique identity.

   The IdentityContexts property specifies the context to select the
   relevant IKE identity to be used during the further IKEAction.  A
   context may be a VPN name or other identifier for selecting the
   appropriate identity for use on the protected IPProtocolEndpoint (or
   collection of IPProtocolEndpoints).

   IdentityContexts is an array of strings.  The multiple values in the
   array are logically ORed together in evaluating the IdentityContexts.
   Each value in the array may be the composition of multiple context
   names.  So, a single value may be a single context name (e.g.,
   "CompanyXVPN"), or it may be combination of contexts.  When an array
   value is a composition, the individual values are logically ANDed
   together for evaluation purposes and the syntax is:

      <ContextName>[&&<ContextName>]*

   where the individual context names appear in alphabetical order
   (according to the collating sequence for UCS-2).  So, for example,

Top      ToC       Page 18 
   the values "CompanyXVPN", "CompanyYVPN&&TopSecret",
   "CompanyZVPN&&Confidential" means that, for the appropriate
   IPProtocolEndpoint and IdentityType, the contexts are matched if the
   identity specifies "CompanyXVPN", "CompanyYVPN&&TopSecret", or
   "CompanyZVPN&&Confidential".

   The property is defined as follows:

      NAME         IdentityContexts
      DESCRIPTION  Specifies the context in which to select the IKE
                   identity.
      SYNTAX       string array

4.3. The Class IPsecRule

   The class IPsecRule associates Conditions and Actions for IKE phase 2
   negotiations for the IPsec DOI.  The class definition for IPsecRule
   is as follows:

      NAME         IPsecRule
      DESCRIPTION  Associates Conditions and Actions for IKE phase 2
                   negotiations for the IPsec DOI.
      DERIVED FROM SARule
      ABSTRACT     FALSE
      PROPERTIES   same as SARule

4.4. The Association Class IPsecPolicyForEndpoint

   The class IPsecPolicyForEndpoint associates a PolicyGroup with a
   specific network interface.  If an IPProtocolEndpoint of a system
   does not have an IPsecPolicyForEndpoint-associated PolicyGroup, then
   the IPsecPolicyForSystem associated PolicyGroup is used for that
   endpoint.  The class definition for IPsecPolicyForEndpoint is as
   follows:

      NAME         IPsecPolicyForEndpoint
      DESCRIPTION  Associates a policy group to a network interface.
      DERIVED FROM Dependency (see [CIMCORE])
      ABSTRACT     FALSE
      PROPERTIES   Antecedent[ref IPProtocolEndpoint[0..n]]
                   Dependent[ref PolicyGroup[0..1]]

4.4.1. The Reference Antecedent

   The property Antecedent is inherited from Dependency and is
   overridden to refer to an IPProtocolEndpoint instance.  The [0..n]
   cardinality indicates that a PolicyGroup instance may be associated
   with zero or more IPProtocolEndpoint instances.

Top      ToC       Page 19 
4.4.2. The Reference Dependent

   The property Dependent is inherited from Dependency and is overridden
   to refer to a PolicyGroup instance.  The [0..1] cardinality indicates
   that an IPProtocolEndpoint instance may have an association to at
   most one PolicyGroup instance.

4.5. The Association Class IPsecPolicyForSystem

   The class IPsecPolicyForSystem associates a PolicyGroup with a
   specific system.  If an IPProtocolEndpoint of a system does not have
   an IPsecPolicyForEndpoint-associated PolicyGroup, then the
   IPsecPolicyForSystem associated PolicyGroup is used for that
   endpoint.  The class definition for IPsecPolicyForSystem is as
   follows:

      NAME         IPsecPolicyForSystem
      DESCRIPTION  Default policy group for a system.
      DERIVED FROM Dependency (see [CIMCORE])
      ABSTRACT     FALSE
      PROPERTIES   Antecedent[ref System[0..n]]
                   Dependent[ref PolicyGroup[0..1]]

4.5.1. The Reference Antecedent

   The property Antecedent is inherited from Dependency and is
   overridden to refer to a System instance.  The [0..n] cardinality
   indicates that a PolicyGroup instance may have an association to zero
   or more System instances.

4.5.2. The Reference Dependent

   The property Dependent is inherited from Dependency and is overridden
   to refer to a PolicyGroup instance.  The [0..1] cardinality indicates
   that a System instance may have an association to at most one
   PolicyGroup instance.

4.6. The Aggregation Class SAConditionInRule

   The class SAConditionInRule associates an SARule with the SACondition
   instance(s) that trigger(s) it.  The class definition for
   SAConditionInRule is as follows:

      NAME         SAConditionInRule
      DESCRIPTION  Associates an SARule with the SACondition instance(s)
                   that trigger(s) it.
      DERIVED FROM PolicyConditionInPolicyRule (see [PCIM] & [PCIME])
      ABSTRACT     FALSE

Top      ToC       Page 20 
      PROPERTIES   GroupNumber (from PolicyConditionInPolicyRule)
                   ConditionNegated (from PolicyConditionInPolicyRule)
                   GroupComponent [ref SARule [0..n]]
                   PartComponent [ref SACondition [1..n]]

4.6.1. The Properties GroupNumber and ConditionNegated

   For a description of these properties, see [PCIM].

4.6.2. The Reference GroupComponent

   The property GroupComponent is inherited from
   PolicyConditionInPolicyRule and is overridden to refer to an SARule
   instance.  The [0..n] cardinality indicates that an SACondition
   instance may be contained in zero or more SARule instances.

4.6.3. The Reference PartComponent

   The property PartComponent is inherited from
   PolicyConditionInPolicyRule and is overridden to refer to an
   SACondition instance.  The [1..n] cardinality indicates that an
   SARule instance MUST contain at least one SACondition instance.

4.7. The Aggregation Class PolicyActionInSARule

   The PolicyActionInSARule class associates an SARule with one or more
   PolicyAction instances.  In all cases where an SARule is being used,
   the contained actions MUST be either subclasses of SAAction or
   instances of CompoundPolicyAction.  For an IKERule, the contained
   actions MUST be related to phase 1 processing, i.e., IKEAction or
   IKERejectAction.  Similarly, for an IPsecRule, contained actions MUST
   be related to phase 2 or preconfigured SA processing, e.g.,
   IPsecTransportAction, IPsecBypassAction, etc.  The class definition
   for PolicyActionInSARule is as follows:

      NAME         PolicyActionInSARule
      DESCRIPTION  Associates an SARule with its PolicyAction(s).
      DERIVED FROM PolicyActionInPolicyRule (see [PCIM] & [PCIME])
      ABSTRACT     FALSE
      PROPERTIES   GroupComponent [ref SARule [0..n]]
                   PartComponent [ref PolicyAction [1..n]]
                   ActionOrder (from PolicyActionInPolicyRule)

Top      ToC       Page 21 
4.7.1. The Reference GroupComponent

   The property GroupComponent is inherited from
   PolicyActionInPolicyRule and is overridden to refer to an SARule
   instance.  The [0..n] cardinality indicates that an SAAction instance
   may be contained in zero or more SARule instances.

4.7.2. The Reference PartComponent

   The property PartComponent is inherited from PolicyActionInPolicyRule
   and is overridden to refer to an SAAction or CompoundPolicyAction
   instance.  The [1..n] cardinality indicates that an SARule instance
   MUST contain at least one SAAction or CompoundPolicyAction instance.

4.7.3. The Property ActionOrder

   The property ActionOrder is inherited from the superclass
   PolicyActionInPolicyRule.  It specifies the relative position of this
   PolicyAction in the sequence of actions associated with a PolicyRule.
   The ActionOrder MUST be unique so as to provide a deterministic
   order.  In addition, the actions in an SARule are executed as
   follows.  See section 4.2.2, ExecutionStrategy, for a discussion on
   the use of the ActionOrder property.

   The property is defined as follows:

      NAME         ActionOrder
      DESCRIPTION  Specifies the order of actions.
      SYNTAX       unsigned 16-bit integer
      VALUE        Any value between 1 and 2^16-1 inclusive.  Lower
                   values have higher precedence (i.e., 1 is the
                   highest precedence).  The merging order of two
                   SAActions with the same precedence is undefined.


Next RFC Part