RFC 3585
IPsec Configuration Policy Information Model
Pages: 88
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 21
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).
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
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].
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:
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
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 |
+--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)
| | |
| | +--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
|
+--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)
|
+--ContainedProposal
|
+--ContainedTransform
|
+--PolicyActionStructure (PCIMe)
| |
| +--PolicyActionInPolicyRule (PCIM & PCIMe)
| |
| +--PolicyActionInSARule
|
+--PolicyConditionStructure (PCIMe)
| |
| +--PolicyConditionInPolicyRule (PCIM & PCIMe)
| |
| +--SAConditionInRule
|
+--PolicySetComponent (PCIMe)
SystemSettingContext (DMTF Core Model)
|
+--AutostartIKESettingContext
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 | +---------+ +-----------+ +----------+
(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
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".
- 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.
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.
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.
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,
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.
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
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)
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.