Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3585

IPsec Configuration Policy Information Model

Pages: 88
Proposed Standard
Part 1 of 4 – Pages 1 to 21
None   None   Next

Top   ToC   RFC3585 - 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   ToC   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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   RFC3585 - 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.