RFC 3585
IPsec Configuration Policy Information Model
IPsec Configuration Policy Information Model 🎀
okay bestie, this is RFC 3585 and it's giving policy modeling 🧚✨. It was written by J. Jason (Intel Corporation), L. Rafalow (IBM), and E. Vyncke (Cisco Systems) in August 2003. It's a Standards Track document, so it's an official Internet standards-track protocol spec. The title block doesn't list any RFC it obsoletes or updates, so it stands on its own 💅.
Status of This Memo 📜
this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share it with everyone 🌈.
Copyright Notice ©
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract 🦋
okay so this document presents an object-oriented information model of IP Security (IPsec) policy. the goal is to help everyone agree on what IPsec policy contains and what it means, and to make it easy to derive task-specific versions of that policy, like a storage schema, distribution formats, and policy specification languages used to configure IPsec-enabled endpoints 🔥. the model covers the configuration parameters defined by IPsec, and it also covers the parameters used by the Internet Key Exchange protocol (IKE). other key exchange protocols could easily be added with a simple extension, and because the model is object-oriented, more extensions can be added easily too 🎀.
this information model is based on the core policy classes from the Policy Core Information Model (PCIM) and 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...................................... 881. Introduction ✨
okay so IPsec policy can take a bunch of different forms as it moves from storage, to distribution, to the places where decisions get made 🧚. at each step it needs to be represented in whatever way is most convenient for the task at hand. for example, the policy could exist as, but is not limited to:
- A Lightweight Directory Access Protocol (LDAP) [LDAP] schema in a directory. 📂
- An on-the-wire representation over a transport protocol like the Common Object Policy Service (COPS) [COPS, COPSPR]. 🛰️
- A text-based policy specification language suitable for editing by an administrator. ✏️
- 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 that idea 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, thanks to its object-oriented nature 🌸.
this document is organized as follows:
- Section 2 gives a quick intro to the Unified Modeling Language (UML) graphical notation conventions used in this document. 🎨
- Section 3 gives the inheritance hierarchy that shows 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). 🌳
- Sections 4 through 8 describe the classes that make up the IPsec policy model. 🧩
- 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 ✨
okay so the author picked a UML static class diagram as the main way to show the IPsec policy model, bc UML gives you a graphical, task-independent way to model systems 🧚 a full treatise on UML's graphical notation is beyond this doc (not me going down that rabbit hole 💀), but since the class diagrams here are drawn in ASCII, here's the lowdown on the notation used in this doc:
- Boxes represent classes, with class names in brackets (
[]) representing an abstract class. 🎀 - 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. 🦋 - 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. 💜
- A line that begins with an
"o"denotes aggregation. Aggregation denotes containment in which the contained class and the containing class have independent lifetimes. 🌸 - 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 for0..n. - the letter
nindicating from 1 to many. The letternis shorthand for1..n. 🍓
- a range in the form
- 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). So the diagrams are a mental model, not a blueprint you copy line by line 💅
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). Here's the inheritance hierarchy for the IPsec Policy Model classes and how they slot 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 aren't used as a superclass to derive new classes, and are only used as references, aren't included in this tree, but you can find them in the appropriate DMTF document: Core Model [CIMCORE], User Model [CIMUSER] or Network Model [CIMNETWORK]. Main character energy for the classes that actually do the work 👑
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)
|
+--AutostartIKEConfigurationThe 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). The association classes get their own little family tree too, so no class gets left out of the group chat 🫶
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)
|
+--AutostartIKESettingContext4. Policy Classes ✨
okay so the IPsec policy classes are basically the whole collection of policies living on a system 🎀 the set of stuff a box is actually enforcing. here's the big picture diagram, bestie 🦋
+--------------+
| [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])so a PolicyGroup is the set of policies used on an interface 🌸 it SHOULD be tied either straight to the IPProtocolEndpoint instance that represents that interface (through the IPsecPolicyForEndpoint association), or indirectly (through the IPsecPolicyForSystem association) to the System hosting the interface 💜
the IKE and IPsec rules are what build or negotiate the IPsec Security Association Database (SADB) 🧚 the IPsec rules are the Security Policy Database. the SADB itself isn't modeled in this document, bestie, so we're skipping it 🙈
here's how the IKE and IPsec rules behave (also check section 6 for actions):
- an egress unprotected packet gets checked against the IPsec rules first 👑 if it matches, the SADB gets checked. if there's no matching IPsec SA in the SADB, and the IPsec rule says IKE negotiation is required, the matching IKE rules kick in. then the negotiated or preconfigured SA gets installed in the SADB ✨
- an ingress unprotected packet also hits the IPsec rules first 💅 on a match, the SADB gets checked for a matching IPsec SA. if there's no matching IPsec SA but a preconfigured SA exists, that preconfigured SA gets installed in the IPsec SADB. this behavior should only apply to bypass and discard actions 🥺
- an ingress protected packet hits the IPsec rules first too 🫶 on a match, the SADB gets checked for a matching IPsec SA. if there's no match but a preconfigured SA exists, it gets installed in the IPsec SADB. (no bypass/discard restriction on this one, fr)
- an ingress IKE negotiation packet that isn't part of an existing IKE SA gets checked against the IKE rules 🦋 the SACondition for the IKERule will usually be a PeerIDPayloadFilterEntry (typically for an aggressive mode IKE negotiation) or an IPHeadersFilter. then the negotiated SA gets installed in the SADB 💖
and when an IPsec rule requires an IKE negotiation to get started, the set of IKE rules is checked 🌈 that check is based on the outgoing IKE packet, using IPHeadersFilter entries (typically using the HdrDstAddress property) 🍓
4.1. The Class SARule
the class SARule is the base class for IKERule and IPsecRule 🎀 even though the class is concrete, it MUST not be instantiated 🙅♀️ it's basically a shared connection point for associations to conditions and actions for both kinds of rules. because it derives from PolicyRule, an SARule (and so an IKERule and IPsecRule too) also gets the PolicyRuleValidityPeriod association 💜
every SARule in a valid PolicyGroup MUST have a unique priority number in PolicySetComponent.Priority 🔥 here's the class definition, bestie:
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)
LimitNegotiation4.1.1. The Properties PolicyRuleName, Enabled, ConditionListType,
RuleUsage, Mandatory, SequencedActions, PolicyRoles, and PolicyDecisionStrategy
for what these properties mean, see [PCIM] and [PCIME] 🌸 and 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" ✨
that's the end of part 3, bestie 🌈 keep reading, there's more coming!
4.1.2. The Property ExecutionStrategy ✨
okay so the ExecutionStrategy properties (in the PolicyRule subclasses AND in the CompoundPolicyAction class 💅) decide how the actions inside them get run. it's basically the game plan for the sequenced actions that a rule or compound action bundles together 🎀 for actions in a rule, the PolicyActionInSARule aggregation lines them up into an ordered set. for a compound action, it's PolicyActionInPolicyAction collecting them into an ordered subset 🦋
there are three execution strategies: "Do Until Success", "Do All", and "Do Until Failure" 🌈
"Do Until Success" runs the actions in the ActionOrder given by the aggregation instances, until one single action succeeds 💖 these actions can be evaluated first to see if they're appropriate to run, so it's not just blindly trying each one until something works 🧐 for an initiator, they get tried in ActionOrder until the list runs out or one completes successfully. for example, an IKE initiator might have several IKEActions for the same SACondition. the initiator tries all of them in the order defined by ActionOrder, i.e., it might try a few phase 1 negotiations with different modes (main mode, then aggressive mode) and/or with multiple IKE peers 🔥 for a responder, when there's more than one action in the rule with the "do until success" condition clause, that gives you alternative actions depending on the proposals it receives. for example, the same IKERule can be used to handle aggressive mode and main mode negotiations with different actions. the responder uses the first appropriate action in the list 👑
"Do All" causes all the actions in the aggregated set to run according to their defined order. the execution keeps going regardless of failures 💪
"Do Until Failure" runs all the actions in a predefined order until the first failure in an action instance 💀 heads up: if all of the actions are successful, then the aggregated result is a failure 🙈 this 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 like this:
IPsecRule.ExecutionStrategy='Do All'
|
+---1--- IPsecTunnelAction // set up SA from host to gateway
|
+---2--- IPsecTransportAction // set up SA from host through
// tunnel to remote hostanother example, showing a rule with fallback actions, might look like this:
IPsecRule.ExecutionStrategy='Do Until Success'
|
+---6--- IPsecTransportAction // negotiate SA with peer
|
+---9--- IPsecBypassAction // but if you must, allow in the clearthe CompoundPolicyAction class (see [PCIME]) can be used when building the actions of IKE and IPsec rules, especially when those rules specify both multiple actions and fallback actions 🧩 its ExecutionStrategy property works together with the one in the PolicyRule 🤝
for example, in nesting SAs with a fallback security gateway, the actions of a rule might be structured like this:
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
// hostwith "Do All", a couple of actions can succeed before a later one fails 😭 in that case, some IKE or IPsec actions may already have created SAs. even if the net effect of the aggregated actions is a failure, those created SAs MAY be kept or MAY be deleted 🫶
with "Do All", the IPsec selectors used during IPsec SA negotiation work like this:
- 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 the 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 in the "Do All" aggregation. NB: the granularity is IP address to IP address. 🔍
if that behavior isn't what you want, the alternative is to define several SARules, one for each IPsec SA to be built. that way you can define specific IPsec selectors for every IPsecAction 🎯
4.1.3. The Property LimitNegotiation 🚦
the LimitNegotiation property gets used when processing either an IKE or an IPsec rule 💫
before moving on with a phase 1 negotiation, this property gets checked to see whether the negotiation role of the rule matches the one defined for the negotiation being undertaken (e.g., Initiator, Responder, or Both). if that check fails (e.g., the current role is IKE responder, but the rule specifies IKE initiator), then the IKE negotiation gets stopped 🛑 note that this only applies to new IKE phase 1 negotiations. it has no effect on renegotiation or refresh operations with peers that already have an established SA 🌸
before moving on with a phase 2 negotiation, the LimitNegotiation property of the IPsecRule is checked first, to see if the negotiation role indicated for the rule matches the current negotiation (Initiator, Responder, or Either). this limit only applies to new phase 2 negotiations 🙅♀️ it gets ignored when someone tries to refresh an expiring SA, since either side can start a refresh operation 🔄 the IKE system can tell that a negotiation is a refresh by checking whether the selector information matches an existing SA. if LimitNegotiation doesn't match and the selector corresponds to a new SA, the negotiation gets 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 - both4.2. The Class IKERule 🎀
the class IKERule links Conditions and Actions for IKE phase 1 negotiations 🧚 its class definition looks like this:
NAME IKERule
DESCRIPTION Associates Conditions and Actions for IKE phase 1
negotiations.
DERIVED FROM SARule
ABSTRACT FALSE
PROPERTIES same as SARule, plus
IdentityContexts4.2.1. The Property IdentityContexts 🪪
the IKE service of a security endpoint can 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 together specify a unique identity 💜
the IdentityContexts property specifies the context used to select the relevant IKE identity for the further IKEAction. a context can be a VPN name or some other identifier that picks the right 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 when IdentityContexts is evaluated 🔀 each value in the array can itself be a composition of multiple context names. so a single value can be one context name (e.g., "CompanyXVPN"), or a combination of contexts. when an array value is a composition, the individual values are logically ANDed together for evaluation, and the syntax is:
<ContextName>[&&<ContextName>]*the individual context names appear in alphabetical order (according to the collating sequence for UCS-2). so, for example, the values "CompanyXVPN", "CompanyYVPN&&TopSecret", and "CompanyZVPN&&Confidential" mean that, for the appropriate IPProtocolEndpoint and IdentityType, the contexts match 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 array4.3. The Class IPsecRule 🌷
the class IPsecRule links Conditions and Actions for IKE phase 2 negotiations for the IPsec DOI 💅 its class definition is:
NAME IPsecRule
DESCRIPTION Associates Conditions and Actions for IKE phase 2
negotiations for the IPsec DOI.
DERIVED FROM SARule
ABSTRACT FALSE
PROPERTIES same as SARule4.4. The Association Class IPsecPolicyForEndpoint 🔗
the class IPsecPolicyForEndpoint associates a PolicyGroup with a specific network interface 🦋 if an IPProtocolEndpoint of a system doesn't have an IPsecPolicyForEndpoint-associated PolicyGroup, then the IPsecPolicyForSystem-associated PolicyGroup gets used for that endpoint 🫶 its class definition is:
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 Antecedent property is inherited from Dependency, and it's overridden to refer to an IPProtocolEndpoint instance. the [0..n] cardinality means a PolicyGroup instance can be associated with zero or more IPProtocolEndpoint instances 🌟
4.4.2. The Reference Dependent 👉
the Dependent property is inherited from Dependency, and it's overridden to refer to a PolicyGroup instance. the [0..1] cardinality means an IPProtocolEndpoint instance can 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 doesn't have an IPsecPolicyForEndpoint-associated PolicyGroup, then the IPsecPolicyForSystem-associated PolicyGroup gets used for that endpoint 🧁 its class definition is:
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 Antecedent property is inherited from Dependency, and it's overridden to refer to a System instance. the [0..n] cardinality means a PolicyGroup instance can have an association to zero or more System instances 💜
4.5.2. The Reference Dependent 🦄
the Dependent property is inherited from Dependency, and it's overridden to refer to a PolicyGroup instance. the [0..1] cardinality means a System instance can have an association to at most one PolicyGroup instance 🎀
4.6. The Aggregation Class SAConditionInRule ✨
Okay bestie, SAConditionInRule is the aggregation that links an SARule to the SACondition instance(s) that trigger it. 🎀 Here's the class definition:
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 the details on these two, go check [PCIM]. It's got everything you need. 🌸
4.6.2. The Reference GroupComponent 🦋
The property GroupComponent is inherited from PolicyConditionInPolicyRule, and it's overridden so it refers to an SARule instance. The [0..n] cardinality means an SACondition instance can be contained in zero or more SARule instances, so it's giving flexible 💅
4.6.3. The Reference PartComponent 🧚
The property PartComponent is inherited from PolicyConditionInPolicyRule too, but this time it's overridden to refer to an SACondition instance. The [1..n] cardinality is where it gets strict: an SARule instance MUST contain at least one SACondition instance. No empty rules allowed, periodt 🔥
4.7. The Aggregation Class PolicyActionInSARule 👑
The PolicyActionInSARule class associates an SARule with one or more PolicyAction instances. Whenever 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 is the strict part again: 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 the order is deterministic. On top of that, 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.5. Condition and Filter Classes 🎀
The IPsec condition and filter classes are used to build the "if" part of the IKE and IPsec rules. Here's the big picture:
*+-------------+
+--------------------| SACondition |
| +-------------+
| * |
| |(a)
| 1 |
| +---------------+
| | FilterList |
| |([CIMNETWORK]) |
| +---------------+
| 1 o
|(b) |(c)
| * |
| +-----------------+
| | FilterEntryBase |
| | ([CIMNETWORK]) |
| +-----------------+
| ^
| |
| +-----------------+ | +-----------------------+
| | IPHeadersFilter |----+----| CredentialFilterEntry |
| | ([PCIME]) | | +-----------------------+
| +-----------------+ |
| |
| +-----------------+ | +--------------------------+
| | IPSOFilterEntry |----+----| PeerIDPayloadFilterEntry |
| +-----------------+ +--------------------------+
|
| *+-----------------------------+
+------------| CredentialManagementService |
| ([CIMUSER]) |
+-----------------------------+
(a) FilterOfSACondition
(b) AcceptCredentialsFrom
(c) EntriesInFilterList (see [CIMNETWORK])5.1. The Class SACondition 💅
SACondition is the class that defines the conditions of rules for IKE and IPsec negotiations. Conditions are tied to policy rules through the SAConditionInRule aggregation. It works as an anchor point for hooking various filters up to policy rules via the FilterOfSACondition association. It also decides whether Credentials can be accepted for a particular policy rule, through the AcceptCredentialsFrom association.
Associated objects stand for the parts of the condition that might or might not apply at a given rule evaluation. For example, an AcceptCredentialsFrom evaluation only happens when there's a credential to check against the list of trusted credential management services. Likewise, a PeerIDPayloadFilterEntry only gets evaluated when there's an IDPayload value to compare with the filter. Condition components with no matching values to evaluate are treated as TRUE, unless the protocol has finished without giving the required information. 🫠
The class definition for SACondition is as follows:
NAME SACondition
DESCRIPTION Defines the preconditions for IKE and IPsec
negotiations.
DERIVED FROM PolicyCondition (see [PCIM])
ABSTRACT FALSE
PROPERTIES PolicyConditionName (from PolicyCondition)5.2. The Class IPHeadersFilter 🌸
The class IPHeadersFilter is defined in [PCIME], with the following note:
- To specify 5-tuple filters that apply symmetrically (i.e., they match traffic in both directions of the same flows, which is pretty typical for SPD entries for ingress and egress traffic), the Direction property of the FilterList SHOULD be set to "Mirrored". 🦋
5.3. The Class CredentialFilterEntry 🔐
CredentialFilterEntry defines an equivalence class that matches credentials of IKE peers. Each CredentialFilterEntry has a MatchFieldName, which gets interpreted according to the CredentialManagementService(s) associated with the SACondition (AcceptCredentialsFrom).
These credentials can be X.509 certificates, Kerberos tickets, or other types of credentials obtained during the Phase 1 exchange.
Note: this filter entry will probably be checked while the IKE negotiation takes place. If the check fails, then the IKE negotiation MUST be stopped, and the result of the IKEAction which triggered this negotiation is a failure. 🚨
The class definition for CredentialFilterEntry is as follows:
NAME CredentialFilterEntry
DESCRIPTION Specifies a match filter based on the IKE
credentials.
DERIVED FROM FilterEntryBase (see [CIMNETWORK])
ABSTRACT FALSE
PROPERTIES Name (from FilterEntryBase)
IsNegated (from FilterEntryBase)
MatchFieldName
MatchFieldValue
CredentialType5.3.1. The Property MatchFieldName 🍓
The property MatchFieldName specifies the sub-part of the credential to match against MatchFieldValue. The property is defined as follows:
NAME MatchFieldName
DESCRIPTION Specifies which sub-part of the credential to match.
SYNTAX string
VALUE This is the string representation of a X.509
certificate attribute, e.g.:
- "serialNumber"
- "signatureAlgorithm"
- "issuerName"
- "subjectName"
- "subjectAltName"
- ...5.3.2. The Property MatchFieldValue 💜
The property MatchFieldValue specifies the value to compare with the MatchFieldName in a credential, to figure out whether the credential matches this filter entry. The property is defined as follows:
NAME MatchFieldValue
DESCRIPTION Specifies the value to be matched by the
MatchFieldName.
SYNTAX string
VALUE NB: If the CredentialFilterEntry corresponds to a
DistinguishedName, this value in the CIM class is
represented by an ordinary string value. However, an
implementation must convert this string to a DER-
encoded string before matching against the values
extracted from credentials at runtime.A wildcard mechanism may be used for MatchFieldNames that contain character strings. The MatchFieldValue may contain a wildcard character, *, in the pattern match specification. For example, if the MatchFieldName is "subjectName", then a MatchFieldValue of "cn=*,ou=engineering,o=foo,c=be" will successfully match a certificate whose subject attribute is "cn=Jane Doe,ou=engineering,o=foo,c=be". The wildcard character can stand in for 0 or more characters, as they would be displayed to the user (i.e., a wildcard pattern match operates on displayable character boundaries). ✨
5.3.3. The Property CredentialType 🌈
The property CredentialType specifies the particular type of credential being matched. The property is defined as follows:
NAME CredentialType
DESCRIPTION Defines the type of IKE credentials.
SYNTAX unsigned 16-bit integer
VALUE 1 - X.509 Certificate
2 - Kerberos Ticket5.4. The Class IPSOFilterEntry 🧚
The class IPSOFilterEntry is used to match traffic based on the IP Security Options [IPSO] header values (ClassificationLevel and ProtectionAuthority) as defined in RFC 1108. This kind of filter entry is used to adjust the IPsec encryption level according to the IPSO classification of the traffic (e.g., secret, confidential, restricted, etc.). The class definition for IPSOFilterEntry is as follows:
NAME IPSOFilterEntry
DESCRIPTION Specifies the a match filter based on IP Security
Options.
DERIVED FROM FilterEntryBase (see [CIMNETWORK])
ABSTRACT FALSE
PROPERTIES Name (from FilterEntryBase)
IsNegated (from FilterEntryBase)
MatchConditionType
MatchConditionValue5.4.1. The Property MatchConditionType
okay so MatchConditionType is the knob that picks which IPSO header field we're checking 💅 it's either the traffic classification level or the protection authority. pick your field, bestie 🎀
NAME MatchConditionType
DESCRIPTION Specifies the IPSO header field to be matched.
SYNTAX unsigned 16-bit integer
VALUE 1 - ClassificationLevel
2 - ProtectionAuthority5.4.2. The Property MatchConditionValue
and this one is the actual value we match against once we've picked the field 🦋 MatchConditionValue is the thing the header has to line up with
NAME MatchConditionValue
DESCRIPTION Specifies the value of the IPSO header field to be
matched against.
SYNTAX unsigned 16-bit integer
VALUE The values MUST be one of values listed in RFC 1108
(or any further IANA Assigned Numbers document).
Some examples for ClassificationLevel are:
61 - TopSecret
90 - Secret
150 - Confidential
171 - Unclassified
For ProtectionAuthority, some examples are:
0 - GENSER
1 - SIOP-ESI
2 - SCI
3 - NSA
4 - DOE5.5. The Class PeerIDPayloadFilterEntry
the class PeerIDPayloadFilterEntry is the filter that matches ID payload values from the IKE exchange 🔥 it lets you write things like "*@example.com" or "192.0.2.0/24" and actually get a match, which is so iconic
⚠️ tea time: this filter only applies to IKERules when acting as a responder 🍓 and it can be applied right away for aggressive mode, but for main mode the application has to wait
here's how the class is set up 🌸
NAME PeerIDPayloadFilterEntry
DESCRIPTION Specifies a match filter based on IKE identity.
DERIVED FROM FilterEntryBase (see [CIMNETWORK])
ABSTRACT FALSE
PROPERTIES Name (from FilterEntryBase)
IsNegated (from FilterEntryBase)
MatchIdentityType
MatchIdentityValue5.5.1. The Property MatchIdentityType
MatchIdentityType says what kind of identity the peer sent in its ID payload. it's the type tag, so it's giving "label on the box" energy 📦
NAME MatchIdentityType
DESCRIPTION Specifies the ID payload type.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.5.5.2. The Property MatchIdentityValue
and MatchIdentityValue is the filter value we compare against the ID payload, like "*@example.com" 💜
NAME MatchIdentityValue
DESCRIPTION Specifies the ID payload value.
SYNTAX string
VALUE NB: The syntax may need to be converted for
comparison. If the PeerIDPayloadFilterEntry type is
a DistinguishedName, the name in the
MatchIdentityValue property is represented by an
ordinary string value, but this value must be
converted into a DER-encoded string before matching
against the values extracted from IKE ID payloads at
runtime. The same applies to IPv4 & IPv6 addresses.okay now the wildcards, and they're honestly so fun 🙈 different ID payload types get different wildcard styles:
"*@example.com"will match a user FQDN ID payload of"JDOE@EXAMPLE.COM"."*.example.com"will match a FQDN ID payload of"WWW.EXAMPLE.COM"."cn=*,ou=engineering,o=company,c=us"will match a DER DN ID payload of"cn=John Doe,ou=engineering,o=company,c=us"."193.190.125.0/24"will match an IPv4 address ID payload of193.190.125.10."193.190.125.*"will also match an IPv4 address ID payload of193.190.125.10.
the big rule here is that the wildcard mechanisms above MUST be supported for every ID payload the local IKE entity supports 🫶 and the '*' character stands in for 0 or more instances of any character, as limited by whatever type MatchIdentityType says 🌈
5.6. The Association Class FilterOfSACondition
FilterOfSACondition is the matchmaker 💖 it links an SACondition to the FilterList filters that make the condition up
NAME FilterOfSACondition
DESCRIPTION Associates a condition with the filter list that
makes up the individual condition elements.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref FilterList[1..1]]
Dependent [ref SACondition[0..n]]5.6.1. The Reference Antecedent
Antecedent comes from Dependency but gets overridden so it points at a FilterList instance 🎀 the [1..1] means every SACondition instance MUST be tied to one and only one FilterList instance, no more, no less 👑
5.6.2. The Reference Dependent
Dependent also comes from Dependency and gets overridden so it points at an SACondition instance 🦋 the [0..n] means a FilterList instance may be linked to zero or more SACondition instances, so it can be a total loner or hang with a whole crew 🧚
5.7. The Association Class AcceptCredentialFrom
AcceptCredentialFrom is the guest list for credential services 🌸 it says which credential management services (like a CertificateAuthority or a Kerberos service) are trusted to certify peer credentials
the whole point is to make sure the credential getting matched in the CredentialFilterEntry is actually valid and came from an approved CredentialManagementService 🔒 so if a CredentialManagementService is listed and a matching CredentialFilterEntry is used, but the peer's credential isn't certified by that service (or any service in its trust hierarchy), then the CredentialFilterEntry is deemed not to match 💀
and here's a fun twist: if a credential IS certified by a service in the AcceptCredentialsFrom list but there's no CredentialFilterEntry at all, that counts the same as a CredentialFilterEntry that matches every credential from those services ✨
the class definition goes like this 🍓
NAME AcceptCredentialFrom
DESCRIPTION Associates a condition with the credential management
services to be trusted.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref CredentialManagementService[0..n]]
Dependent [ref SACondition[0..n]]5.7.1. The Reference Antecedent
Antecedent is inherited from Dependency and overridden to point at a CredentialManagementService instance 💅 the [0..n] means an SACondition instance may be linked to zero or more CredentialManagementService instances
5.7.2. The Reference Dependent
Dependent is inherited from Dependency and overridden to point at an SACondition instance 🫶 the [0..n] means a CredentialManagementService instance may be linked to zero or more SACondition instances
6. Action Classes ⚡
okay the action classes are where the drama happens 🔥 they model the different things an IPsec device can do when its condition gets a match
+----------+
| SAAction |
+----------+
^
|
+-----------+--------------+
| |
| +---------------------+
| | SaNegotiationAction |
| +---------------------+
| ^
| |
+----------------+ +----------------------+*
| SAStaticAction | | IKENegotiationAction |o----+
+----------------+ +----------------------+ |
^ ^ |
| | |
| +-----------+-------+ |
| | | |
+-------------------+ | +-------------+ +-----------+ |
| IPsecBypassAction |---+ | IPsecAction | | IKEAction | |
+-------------------+ | +-------------+ +-----------+ |
| ^ |
+--------------------+ | | +----------------------+ |
| IPsecDiscardAction |---+ +----| IPsecTransportAction | |
+--------------------+ | | +----------------------+ |
| | |
+-----------------+ | | +-------------------+ |
| IKERejectAction |---+ +----| IPsecTunnelAction | |
+-----------------+ | +-------------------+ |
| *| |
| +--------------+ |
| | |
+-----------------------+ | | +--------------+n |
| PreconfiguredSAAction |---+ |(a) | [SAProposal] |-------+
+-----------------------+ | +--------------+ (b)
*| ^ |
| | | *+-------------+
| | +-------| PeerGateway |
| | +-------------+
| | +-----------------------------+ |0..1 *w|
| +--| PreconfiguredTransportAction| | |(c)
| | +-----------------------------+ | 1|
| | | +--------------+
| | +---------------------------+ * | | System |
| +--| PreconfiguredTunnelAction |-----+ | ([CIMCORE]) |
| +---------------------------+ (e) +--------------+
|
| 2..6+---------------+
+-------| [SATransform] |
(d) +---------------+
(a) PeerGatewayForTunnel
(b) ContainedProposal
(c) HostedPeerGatewayInformation
(d) TransformOfPreconfiguredAction
(e) PeerGatewayForPreconfiguredTunnel6.1. The Class SAAction
SAAction is abstract, so it's the base class you never make directly 🌈 it's the parent for both IKE and IPsec actions, and it's used to bundle different kinds of actions up into IKE and IPsec rules 🧁 here's the definition
NAME SAAction
DESCRIPTION The base class for IKE and IPsec actions.
DERIVED FROM PolicyAction (see [PCIM])
ABSTRACT TRUE
PROPERTIES PolicyActionName (from PolicyAction)
DoActionLogging
DoPacketLogging6.1.1. The Property DoActionLogging ✨
okay so DoActionLogging is the bool that decides whether a log message gets generated when the action runs 📝 For SANegotiationActions, it means logging a message when the negotiation is attempted, with the success or failure result. It also applies to SAStaticActions, but only PreconfiguredSAActions, where it means logging a message when the preconfigured SA is actually installed in the SADB 💅
NAME DoActionLogging
DESCRIPTION Specifies the whether to log when the action is
performed.
SYNTAX boolean
VALUE true - a log message is to be generated when action
is performed.
false - no log message is to be generated when action
is performed.6.1.2. The Property DoPacketLogging 🎀
DoPacketLogging is giving "log when the SA actually touches a packet" 👀 It decides whether a log message gets generated when the resulting security association is used to process the packet. If a SANegotiationAction runs successfully and creates one or several SAs, or if a PreconfiguredSAAction executes, the DoPacketLogging value SHOULD be propagated to an optional field of the SADB 🫶 That optional field should be used to decide whether a log message is generated when the SA processes a packet. For SAStaticActions, a log message is generated when IPsecBypassAction, IPsecDiscardAction, or IKERejectAction runs 🔥
NAME DoPacketLogging
DESCRIPTION Specifies whether to log when the resulting
security association is used to process the packet.
SYNTAX boolean
VALUE true - a log message is to be generated when the
resulting security association is used to process the
packet.
false - no log message is to be generated.6.2. The Class SAStaticAction 🌸
SAStaticAction is abstract, and it's the base class for IKE and IPsec actions that don't need any negotiation 🦋 Here's the class definition:
NAME SAStaticAction
DESCRIPTION The base class for IKE and IPsec actions that do not
require any negotiation.
DERIVED FROM SAAction
ABSTRACT TRUE
PROPERTIES LifetimeSeconds6.2.1. The Property LifetimeSeconds ⏳
LifetimeSeconds is how long the security association derived from this action should be used ⏰ Defined like this:
NAME LifetimeSeconds
DESCRIPTION Specifies the amount of time (in seconds) that a
security association derived from this action should
be used.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there is not a
lifetime associated with this action (i.e., infinite
lifetime). A non-zero value is typically used in
conjunction with alternate SAActions performed when
there is a negotiation failure of some sort.Note: if the referenced SAStaticAction object is a PreconfiguredSAAction associated to several SATransforms, then the actual lifetime of the preconfigured SA is the lesser of this LifetimeSeconds value and the MaxLifetimeSeconds value of the associated SATransform. If the LifetimeSeconds value is zero, then there is no lifetime associated to this SA 💜
Note: while some SA negotiation protocols [IKE] can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient 🧚
It is expected that most SAStaticAction instances will have their LifetimeSeconds properties set to zero, meaning the resulting SA never expires 🌈
6.3. The Class IPsecBypassAction 🍓
IPsecBypassAction is used when packets are allowed to be processed without IPsec encapsulation applied. That's the same as saying packets are allowed to flow in the clear 🕊️ Class definition:
NAME IPsecBypassAction
DESCRIPTION Specifies that packets are to be allowed to pass in
the clear.
DERIVED FROM SAStaticAction
ABSTRACT FALSE6.4. The Class IPsecDiscardAction 🚫
IPsecDiscardAction is used when packets are to be discarded, which is the same as saying packets are to be denied 🙅♀️ Class definition:
NAME IPsecDiscardAction
DESCRIPTION Specifies that packets are to be discarded.
DERIVED FROM SAStaticAction
ABSTRACT FALSE6.5. The Class IKERejectAction 🛑
IKERejectAction is used to prevent an IKE negotiation from being attempted with the peer(s) 🧱 The main use of this class is to prevent some denial of service attacks when acting as IKE responder 😭 It goes beyond a plain discard of UDP/500 IKE packets because the SACondition can be based on a specific PeerIDPayloadFilterEntry (when aggressive mode is used) 💅 Class definition:
NAME IKERejectAction
DESCRIPTION Specifies that an IKE negotiation should not even be
attempted or continued.
DERIVED FROM SAStaticAction
ABSTRACT FALSE6.6. The Class PreconfiguredSAAction 🔐
PreconfiguredSAAction is used to create a security association using preconfigured, hard-wired algorithms and keys 🗝️
Notes:
- the SPI for a PreconfiguredSAAction is contained in the association, TransformOfPreconfiguredAction;
- the session key (if applicable) is contained in an instance of the class SharedSecret (see [CIMUSER]). The session key is stored in the property
Secret. The propertyprotocolcontains either"ESP-encrypt","ESP-auth"or"AH". The propertyalgorithmcontains the algorithm used to protect the secret (it can be"PLAINTEXT"if the IPsec entity has no secret storage). The value of propertyRemoteIDis the concatenation of the remote IPsec peer IP address in dotted decimal, the character"/","IN"(respectively"OUT") for an inbound SA (respectively outbound SA), the character"/", and the hexadecimal representation of the SPI.
Although the class is concrete, it MUST not be instantiated 🚨 Here's the class definition:
NAME PreconfiguredSAAction
DESCRIPTION Specifies preconfigured algorithm and keying
information for creation of a security association.
DERIVED FROM SAStaticAction
ABSTRACT TRUE
PROPERTIES LifetimeKilobytes6.6.1. The Property LifetimeKilobytes 📊
LifetimeKilobytes is a traffic limit in kilobytes that can be consumed before the SA gets deleted 🗑️ Defined as:
NAME LifetimeKilobytes
DESCRIPTION Specifies the SA lifetime in kilobytes.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there is not a
lifetime associated with this action (i.e., infinite
lifetime). A non-zero value is used to indicate that
after this number of kilobytes has been consumed the
SA must be deleted from the SADB.Note: the actual lifetime of the preconfigured SA is the lesser of this LifetimeKilobytes value and the MaxLifetimeSeconds value of the associated SATransform. If the LifetimeKilobytes value is zero, then there is no lifetime associated with this action.
Note: while some SA negotiation protocols [IKE] can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient.
It is expected that most PreconfiguredSAAction instances will have their LifetimeKilobyte properties set to zero, meaning the resulting SA never expires 🌷
6.7. The Class PreconfiguredTransportAction 🚚
PreconfiguredTransportAction is used to create an IPsec transport-mode security association using preconfigured, hard-wired algorithms and keys 🧦 Class definition:
NAME PreconfiguredTransportAction
DESCRIPTION Specifies preconfigured algorithm and keying
information for creation of an IPsec transport
security association.
DERIVED FROM PreconfiguredSAAction
ABSTRACT FALSE6.8. The Class PreconfiguredTunnelAction 🚇
PreconfiguredTunnelAction is used to create an IPsec tunnel-mode security association using preconfigured, hard-wired algorithms and keys 🔧 The class definition for PreconfiguredSAAction is as follows:
NAME PreconfiguredTunnelAction
DESCRIPTION Specifies preconfigured algorithm and keying
information for creation of an IPsec tunnel-mode
security association.
DERIVED FROM PreconfiguredSAAction
ABSTRACT FALSE
PROPERTIES DFHandling6.8.1. The Property DFHandling 🏳️
DFHandling says how the Don't Fragment (DF) bit of the internal IP header gets handled during IPsec processing 🪄 Defined as:
NAME DFHandling
DESCRIPTION Specifies the processing of the DF bit.
SYNTAX unsigned 16-bit integer
VALUE 1 - Copy the DF bit from the internal IP header to
the external IP header.
2 - Set the DF bit of the external IP header to 1.
3 - Clear the DF bit of the external IP header to 0.6.9. The Class SANegotiationAction 🤝
SANegotiationAction specifies an action that requests security policy negotiation 💬
This is an abstract class. Right now, only one security policy negotiation protocol action is subclassed from SANegotiationAction: the IKENegotiationAction class. It's still expected that other security policy negotiation protocols will exist, and their negotiation actions would be modeled as subclasses of SANegotiationAction 🌟
NAME SANegotiationAction
DESCRIPTION Specifies a negotiation action.
DERIVED FROM SAAction
ABSTRACT TRUE6.10. The Class IKENegotiationAction 🌙
IKENegotiationAction is abstract and serves as the base class for IKE and IPsec actions that result in an IKE negotiation 🫧 It specifies the parameters that are common to IKE phase 1 and IKE phase 2 IPsec DOI negotiations. Class definition:
NAME IKENegotiationAction
DESCRIPTION A base class for IKE and IPsec actions that specifies
the parameters that are common for IKE phase 1 and
IKE phase 2 IPsec DOI negotiations.
DERIVED FROM SANegotiationAction
ABSTRACT TRUE
PROPERTIES MinLifetimeSeconds
MinLifetimeKilobytes
IdleDurationSeconds6.10.1. The Property MinLifetimeSeconds ✨
okay so MinLifetimeSeconds is the floor for how many seconds a lifetime can be before we accept it from the peer 🛡️. Why does it matter? A sneaky peer could ask for an arbitrarily tiny lifetime, which forces renegotiations with super expensive Diffie-Hellman operations over and over. That's a denial of service attack, and it is NOT it, bestie 🙅♀️💀
NAME MinLifetimeSeconds
DESCRIPTION Specifies the minimum seconds acceptable in a
lifetime.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there is no minimum
value. A non-zero value specifies the minimum
seconds lifetime.Note: ngl, IKE can negotiate the lifetime as an arbitrary length field, but the authors have assumed that a 64-bit integer will be sufficient 🤷♀️
6.10.2. The Property MinLifetimeKilobytes 🦋
MinLifetimeKilobytes is the kilobytes version of the same idea: it sets the minimum kilobytes of a lifetime that will be accepted from the peer 💅. It's there to stop the same denial of service move, where the peer asks for a ridiculously low lifetime and makes you redo those pricey Diffie-Hellman operations.
Here's the tea 🍵: there has been a LOT of debate about whether kilobyte lifetimes even make sense for IKE phase 1 security associations. So it's likely that this property will only apply to the sub-class IPsecAction. Iconic plot twist 😭
NAME MinLifetimeKilobytes
DESCRIPTION Specifies the minimum kilobytes acceptable in a
lifetime.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there is no minimum
value. A non-zero value specifies the minimum
kilobytes lifetime.Note: While IKE can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient 🌸
6.10.3. The Property IdleDurationSeconds 🧚
IdleDurationSeconds tracks how many seconds a security association can sit idle (aka no traffic protected by it) before it gets deleted 🗑️ Idle means nobody is using it, and it's getting cleaned up. Main character energy for SAs that actually get used ✨
NAME IdleDurationSeconds
DESCRIPTION Specifies how long, in seconds, a security
association may remain unused before it is deleted.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that idle detection should
not be used for the security association (only the
seconds and kilobyte lifetimes will be used). Any
non-zero value indicates the number of seconds the
security association may remain unused.So a value of zero means idle detection is off for that SA, and only the seconds and kilobyte lifetimes do the work 🫶 Any non-zero value is the number of seconds the SA may stay unused.
6.11. The Class IPsecAction 💜
okay the IPsecAction class is the base class for IPsec transport and tunnel actions 🎀 It sets the parameters used for an IKE phase 2 IPsec DOI negotiation. Basically, it's the template that the transport and tunnel vibes are built on.
NAME IPsecAction
DESCRIPTION A base class for IPsec transport and tunnel actions
that specifies the parameters for IKE phase 2 IPsec
DOI negotiations.
DERIVED FROM IKENegotiationAction
ABSTRACT TRUE
PROPERTIES UsePFS
UseIKEGroup
GroupId
Granularity
VendorID6.11.1. The Property UsePFS 🔐
UsePFS decides whether or not perfect forward secrecy should be used when refreshing keys 🔑 It's a yes or no switch, and it's giving very on/off energy.
NAME UsePFS
DESCRIPTION Specifies the whether or not to use PFS when
refreshing keys.
SYNTAX boolean
VALUE A value of true indicates that PFS should be used. A
value of false indicates that PFS should not be used.6.11.2. The Property UseIKEGroup 💖
UseIKEGroup says whether or not phase 2 should use the same key exchange group that phase 1 used 👯♀️ Fun detail: UseIKEGroup gets ignored completely if UsePFS is false. Nothing to see here, bestie 🙈
NAME UseIKEGroup
DESCRIPTION Specifies whether or not to use the same GroupId for
phase 2 as was used in phase 1. If UsePFS is false,
then UseIKEGroup is ignored.
SYNTAX boolean
VALUE A value of true indicates that the phase 2 GroupId
should be the same as phase 1. A value of false
indicates that the property GroupId will contain the
key exchange group to use for phase 2.6.11.3. The Property GroupId 🌈
GroupId names the key exchange group to use for phase 2 🧩 It only actually matters when UsePFS is true AND UseIKEGroup is false. It gets ignored if (1) UsePFS is false, or (2) UsePFS is true and UseIKEGroup is true. Too many conditions, I know, but that's the vibe 😭
If the GroupID number is from the vendor-specific range (32768-65535), then the property VendorID qualifies the group number 🏷️
NAME GroupId
DESCRIPTION Specifies the key exchange group to use for phase 2
when the property UsePFS is true and the property
UseIKEGroup is false.
SYNTAX unsigned 16-bit integer
VALUE Consult [IKE] for valid values.6.11.4. The Property Granularity 🔍
Granularity tells us how the selector for the security association should be derived from the traffic that triggered the negotiation 🕵️♀️ Basically, how specific do we get when we're building the selector? There are four levels, and they're all very different.
NAME Granularity
DESCRIPTION Specifies how the proposed selector for the
security association will be created.
SYNTAX unsigned 16-bit integer
VALUE 1 - subnet: the source and destination subnet masks
of the filter entry are used.
2 - address: only the source and destination IP
addresses of the triggering packet are used.
3 - protocol: the source and destination IP addresses
and the IP protocol of the triggering packet are
used.
4 - port: the source and destination IP addresses and
the IP protocol and the source and destination layer
4 ports of the triggering packet are used.So here's the breakdown 🎀: 1 goes by subnet masks from the filter entry, 2 looks only at the source and destination IP addresses, 3 adds the IP protocol, and 4 goes all the way down to the layer 4 ports too 🔥
6.11.5. The Property VendorID 🏳️🌈
VendorID works together with GroupID (when that GroupID is in the vendor-specific range) to identify the key exchange group 🤝 It gets ignored unless UsePFS is true, UseIKEGroup is false, AND GroupID is in the vendor-specific range (32768-65535). Lots of ANDs, lots of rules, very specific girlboss energy 💅
NAME VendorID
DESCRIPTION Specifies the IKE Vendor ID.
SYNTAX string6.12. The Class IPsecTransportAction 🚀
The IPsecTransportAction class is a subclass of IPsecAction, and it's used to specify use of an IPsec transport-mode security association 🦋 It's the transport-mode lane, sis.
NAME IPsecTransportAction
DESCRIPTION Specifies that an IPsec transport-mode security
association should be negotiated.
DERIVED FROM IPsecAction
ABSTRACT FALSE6.13. The Class IPsecTunnelAction 🌷
The IPsecTunnelAction class is also a subclass of IPsecAction 🫧 This one is used to specify use of an IPsec tunnel-mode security association. Tunnel-mode girlies, this one's for you 💜
NAME IPsecTunnelAction
DESCRIPTION Specifies that an IPsec tunnel-mode security
association should be negotiated.
DERIVED FROM IPsecAction
ABSTRACT FALSE
PROPERTIES DFHandling6.13.1. The Property DFHandling 🍓
DFHandling specifies how the tunnel should manage the Don't Fragment (DF) bit 📦 It's the tunnel's rule for what happens to that bit.
NAME DFHandling
DESCRIPTION Specifies how to process the DF bit.
SYNTAX unsigned 16-bit integer
VALUE 1 - Copy the DF bit from the internal IP header to
the external IP header.
2 - Set the DF bit of the external IP header to 1.
3 - Clear the DF bit of the external IP header to 0.So there are three options 🎀: 1 copies the DF bit from the internal IP header to the external one, 2 sets the external DF bit to 1, and 3 clears the external DF bit to 0 😌
6.14. The Class IKEAction 👑
The IKEAction class specifies the parameters that are to be used for IKE phase 1 negotiation 🌸 This is the phase 1 setup, the glow-up before the main event.
NAME IKEAction
DESCRIPTION Specifies the IKE phase 1 negotiation parameters.
DERIVED FROM IKENegotiationAction
ABSTRACT FALSE
PROPERTIES ExchangeMode
UseIKEIdentityType
VendorID
AggressiveModeGroupId6.14.1. The Property ExchangeMode 🧁
ExchangeMode specifies which IKE mode should be used for IKE phase 1 negotiations 🎶 Three options exist: base mode, main mode, and aggressive mode, and each one has its own number.
NAME ExchangeMode
DESCRIPTION Specifies the IKE negotiation mode for phase 1.
SYNTAX unsigned 16-bit integer
VALUE 1 - base mode
2 - main mode
4 - aggressive modeYes, the numbers skip 3. Don't ask me why, it's giving mystery 🙈
6.14.2. The Property UseIKEIdentityType 🪪
UseIKEIdentityType specifies what IKE identity type should be used when negotiating with the peer 🤳 This info gets used together with the IKE identities available on the system and the IdentityContexts of the matching IKERule. Teamwork makes the dream work 💕
NAME UseIKEIdentityType
DESCRIPTION Specifies the IKE identity to use during negotiation.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.6.14.3. The Property VendorID 🏷️
VendorID specifies the value to be used in the Vendor ID payload 📬 Here's the fun part: NULL means the Vendor ID payload is neither generated nor accepted, but a non-NULL value means it WILL be generated when you're the initiator, or EXPECTED when you're the responder 🥰
NAME VendorID
DESCRIPTION Vendor ID Payload.
SYNTAX string
VALUE A value of NULL means that Vendor ID payload will be
neither generated nor accepted. A non-NULL value
means that a Vendor ID payload will be generated
(when acting as an initiator) or is expected (when
acting as a responder).6.14.4. The Property AggressiveModeGroupId 🌊
AggressiveModeGroupId specifies which group ID is used in the first packets of the phase 1 negotiation 🚪 It gets ignored unless ExchangeMode is set to 4 (aggressive mode). And if the AggressiveModeGroupID number is from the vendor-specific range (32768-65535), then VendorID is the one that qualifies the group number 🫶
NAME AggressiveModeGroupId
DESCRIPTION Specifies the group ID to be used for aggressive
mode.
SYNTAX unsigned 16-bit integer6.15. The Class PeerGateway 🌍
The PeerGateway class specifies the security gateway that the IKE services negotiate with 🤝 It's the peer you're actually talking to, so it's a big deal.
NAME PeerGateway
DESCRIPTION Specifies the security gateway with which to
negotiate.
DERIVED FROM LogicalElement (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Name
PeerIdentityType
PeerIdentityNote: The class PeerIdentityEntry contains more information about the peer (namely its IP address) 💜
6.15.1. The Property Name ✨
okay so Name is just the user-friendly label for this security gateway 💅 like, the nickname you'd actually recognise on a dashboard. here's the definition:
NAME Name
DESCRIPTION Specifies a user-friendly name for this security
gateway.
SYNTAX string6.15.2. The Property PeerIdentityType 🦋
PeerIdentityType tells you the IKE identity type of the security gateway, so the other side knows what kind of ID it's looking at 🫶 the actual valid values aren't listed here. you have to go check [DOI] for those, so bookmark that bestie 🔖
NAME PeerIdentityType
DESCRIPTION Specifies the IKE identity type of the security
gateway.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.6.15.3. The Property PeerIdentity 🌸
PeerIdentity is the IKE identity value of the security gateway, the actual thing that goes in there. now the tea: the way it's stored in your task-specific mapping of the information model might be different from what goes on the wire, so you may need a conversion from the stored PeerIdentity string to the real value used in the ID payload. the classic example is an IP address. it's stored as a dotted decimal string, but it has to become 4 bytes. it's giving translation layer energy 🧚
NAME PeerIdentity
DESCRIPTION Specifies the IKE identity value of the security
gateway.
SYNTAX string6.16. The Association Class PeerGatewayForTunnel 🎀
okay this one is the matchmaker 💘 PeerGatewayForTunnel links IPsecTunnelActions up with an ordered list of PeerGateways, so the order actually matters. here's the class definition:
NAME PeerGatewayForTunnel
DESCRIPTION Associates IPsecTunnelActions with an ordered list of
PeerGateways.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref PeerGateway[0..n]]
Dependent [ref IPsecTunnelAction[0..n]]
SequenceNumber6.16.1. The Reference Antecedent 👑
the Antecedent is inherited from Dependency, but it gets overridden so it points at a PeerGateway instance. the [0..n] cardinality means an IPsecTunnelAction instance can be linked to zero or more PeerGateway instances.
Note: the cardinality 0 has a very specific meaning, so pay attention 👀
- when the IKE service acts as a responder, this means that the IKE service will accept phase 1 negotiation with any other security gateway;
- when the IKE service acts as an initiator, this means that the IKE service will use the destination IP address (of the IP packets which triggered the SARule) as the IP address of the peer IKE entity.
6.16.2. The Reference Dependent 🧚
the Dependent is also inherited from Dependency and is overridden to point at an IPsecTunnelAction instance. the [0..n] cardinality means a PeerGateway instance can be linked to zero or more IPsecTunnelAction instances. so it's a two-way friendship, no pressure 💜
6.16.3. The Property SequenceNumber 🔥
SequenceNumber sets the order used when evaluating PeerGateway instances for a given IPsecTunnelAction. first in line gets checked first 🏃♀️
NAME SequenceNumber
DESCRIPTION Specifies the order of evaluation for PeerGateways.
SYNTAX unsigned 16-bit integer
VALUE Lower values are evaluated first.6.17. The Aggregation Class ContainedProposal 🌈
the ContainedProposal class is the proposal bundle. it links an ordered list of SAProposals to the IKENegotiationAction that aggregates it. the type rules are super strict and I am obsessed 😭 if the IKENegotiationAction is an IKEAction, the SAProposal objects must be IKEProposal(s). if it's an IPsecTransportAction or an IPsecTunnelAction, the SAProposal objects must be IPsecProposal(s). here's the definition:
NAME ContainedProposal
DESCRIPTION Associates an ordered list of SAProposals with an
IKENegotiationAction.
DERIVED FROM PolicyComponent (see [PCIM])
ABSTRACT FALSE
PROPERTIES GroupComponent[ref IKENegotiationAction[0..n]]
PartComponent[ref SAProposal[1..n]]
SequenceNumber6.17.1. The Reference GroupComponent 💖
- the GroupComponent is inherited from PolicyComponent and gets overridden to point at an IKENegotiationAction instance. the [0..n] cardinality means an SAProposal instance can be associated with zero or more IKENegotiationAction instances.
6.17.2. The Reference PartComponent 🫶
the PartComponent is inherited from PolicyComponent and is overridden to point at an SAProposal instance. the [1..n] cardinality is the strict part 🚨 an IKENegotiationAction instance MUST be associated with at least one SAProposal instance. no empty bundles allowed, periodt.
6.17.3. The Property SequenceNumber 🍓
SequenceNumber here sets the order of preference for the SAProposals.
NAME SequenceNumber
DESCRIPTION Specifies the preference order for the SAProposals.
SYNTAX unsigned 16-bit integer
VALUE Lower-valued proposals are preferred over proposals
with higher values. For ContainedProposals that
reference the same IKENegotiationAction,
SequenceNumber values must be unique.6.18. The Association Class HostedPeerGatewayInformation 🌸
this one is a weak association 🥺 HostedPeerGatewayInformation loosely links a PeerGateway with a System. here's the class definition:
NAME HostedPeerGatewayInformation
DESCRIPTION Weakly associates a PeerGateway with a System.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref System[1..1]]
Dependent [ref PeerGateway[0..n] [weak]]6.18.1. The Reference Antecedent 💅
the Antecedent is inherited from Dependency and is overridden to point at a System instance. the [1..1] cardinality means a PeerGateway instance MUST be associated with one and only one System instance. one host, no sharing the spotlight ✨
6.18.2. The Reference Dependent 🦋
the Dependent is inherited from Dependency and is overridden to point at a PeerGateway instance. the [0..n] cardinality means a System instance can be associated with zero or more PeerGateway instances.
6.19. The Association Class TransformOfPreconfiguredAction 🧚
TransformOfPreconfiguredAction ties a PreconfiguredSAAction to two, four or six SATransforms, which get applied to the inbound and outbound traffic. the order those transforms get applied in is implicitly defined in [IPSEC], so go read that if you're curious 📖 here's the definition:
NAME TransformOfPreconfiguredAction
DESCRIPTION Associates a PreconfiguredSAAction with from one to
three SATransforms.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent[ref SATransform[2..6]]
Dependent[ref PreconfiguredSAAction[0..n]]
SPI
Direction6.19.1. The Reference Antecedent 🌈
the Antecedent is inherited from Dependency and is overridden to point at an SATransform instance. the [2..6] cardinality means a PreconfiguredSAAction instance can be associated with two to six SATransform instances.
6.19.2. The Reference Dependent 💜
the Dependent is inherited from Dependency and is overridden to point at a PreconfiguredSAAction instance. the [0..n] cardinality means an SATransform instance can be associated with zero or more PreconfiguredSAAction instances.
6.19.3. The Property SPI 🔥
SPI is the SPI the pre-configured action uses for the associated transform.
NAME SPI
DESCRIPTION Specifies the SPI to be used with the SATransform.
SYNTAX unsigned 32-bit integer6.19.4. The Property Direction 🎀
Direction says whether the SPI property is for inbound or outbound traffic. two options, pick your side 🙈
NAME Direction
DESCRIPTION Specifies whether the SA is for inbound or outbound
traffic.
SYNTAX unsigned 8-bit integer
VALUE 1 - this SA is for inbound traffic
2 - this SA is for outbound traffic6.20 The Association Class PeerGatewayForPreconfiguredTunnel 🍓
PeerGatewayForPreconfiguredTunnel associates zero or one PeerGateways with multiple PreconfiguredTunnelActions. it's a little bit of a situationship 💀 here's the definition:
NAME PeerGatewayForPreconfiguredTunnel
DESCRIPTION Associates a PeerGateway with multiple
PreconfiguredTunnelActions.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent[ref PeerGateway[0..1]]
Dependent[ref PreconfiguredTunnelAction[0..n]]6.20.1. The Reference Antecedent 🧚
the Antecedent is inherited from Dependency and is overridden to point at a PeerGateway instance. the [0..1] cardinality means a PreconfiguredTunnelAction instance can be associated with one PeerGteway instance.
6.20.2. The Reference Dependent 🌸
the Dependent is inherited from Dependency and is overridden to point at a PreconfiguredTunnelAction instance. the [0..n] cardinality means a PeerGateway instance can be associated with zero or more PreconfiguredSAAction instances.
7. Proposal and Transform Classes ✨
okay this section is the menu 🍽️ the proposal and transform classes model the proposal settings an IPsec device uses during IKE phase 1 and 2 negotiations. here's the big picture:
+--------------+*w 1+--------------+
| [SAProposal] |--------| System |
+--------------+ (a) | ([CIMCORE]) |
^ +--------------+
| |1
+----------------------+ |
| | |
+-------------+ +---------------+ |
| IKEProposal | | IPsecProposal | |
+-------------+ +---------------+ |
*o |
|(b) |(c)
n| |
+---------------+*w |
| [SATransform] |----+
+---------------+
^
|
+--------------------+-----------+---------+
| | |
+-------------+ +--------------+ +----------------+
| AHTransform | | ESPTransform | |IPCOMPTransform |
+-------------+ +--------------+ +----------------+
(a) SAProposalInSystem
(b) ContainedTransform
(c) SATransformInSystem7.1. The Abstract Class SAProposal 💖
the abstract SAProposal class is the base class for the IKE and IPsec proposal classes 🫶 it holds the parameters both proposal types have in common. here's the class definition:
NAME SAProposal
DESCRIPTION Specifies the common proposal parameters for IKE and
IPsec security association negotiation.
DERIVED FROM Policy ([PCIM])
ABSTRACT TRUE
PROPERTIES Name7.1.1. The Property Name
okay so the property Name is basically the user-friendly name for the SAProposal 🎀 it's the label that makes a proposal easy to recognise, and here's how it's defined:
NAME Name
DESCRIPTION Specifies a user-friendly name for this proposal.
SYNTAX string7.2. The Class IKEProposal
the IKEProposal class is where the magic happens 🦋 it holds the proposal parameters you need to drive an IKE security association negotiation. here's the class definition:
NAME IKEProposal
DESCRIPTION Specifies the proposal parameters for IKE security
association negotiation.
DERIVED FROM SAProposal
ABSTRACT FALSE
PROPERTIES CipherAlgorithm
HashAlgorithm
PRFAlgorithm
GroupId
AuthenticationMethod
MaxLifetimeSeconds
MaxLifetimeKilobytes
VendorID7.2.1. The Property CipherAlgorithm
the property CipherAlgorithm is how you specify the proposed phase 1 security association encryption algorithm 🔐 bestie, the definition:
NAME CipherAlgorithm
DESCRIPTION Specifies the proposed encryption algorithm for the
phase 1 security association.
SYNTAX unsigned 16-bit integer
VALUE Consult [IKE] for valid values.7.2.2. The Property HashAlgorithm
the property HashAlgorithm specifies the proposed phase 1 security association hash algorithm ✨ it's giving integrity check vibes. here's the definition:
NAME HashAlgorithm
DESCRIPTION Specifies the proposed hash algorithm for the phase 1
security association.
SYNTAX unsigned 16-bit integer
VALUE Consult [IKE] for valid values.7.2.3. The Property PRFAlgorithm
the property PRFAlgorithm specifies the proposed phase 1 security association pseudo-random function 🌸 this one's a little bit of a plot twist, because there are none defined in [IKE] right now 💀 if [IKE, DOI] get extended, though, their values are the ones to use. the definition:
NAME PRFAlgorithm
DESCRIPTION Specifies the proposed pseudo-random function for the
phase 1 security association.
SYNTAX unsigned 16-bit integer
VALUE Currently none defined in [IKE], if [IKE, DOI] are
extended, then the values of [IKE, DOI] are to be
used for values of PRFAlgorithm.7.2.4. The Property GroupId
the property GroupId specifies the proposed phase 1 security association key exchange group 👑 slay, but there's a twist: this property is ignored for all aggressive mode exchanges 🙈 and if the GroupID number is from the vendor-specific range (32768-65535), the property VendorID qualifies the group number. the definition:
NAME GroupId
DESCRIPTION Specifies the proposed key exchange group for the
phase 1 security association.
SYNTAX unsigned 16-bit integer
VALUE Consult [IKE] for valid values.📝 Note: The value of this property is to be ignored in aggressive mode.
7.2.5. The Property AuthenticationMethod
the property AuthenticationMethod specifies the proposed phase 1 authentication method 🔑 this one is lowkey iconic because a value of 0 is a special case. it means this proposal should be repeated once for each authentication method that matches the credentials installed on the machine 🫶 so if the system has a pre-shared key and a certificate, your proposal list could include a pre-shared key proposal plus proposals for any of the public-key authentication methods. the definition:
NAME AuthenticationMethod
DESCRIPTION Specifies the proposed authentication method for the
phase 1 security association.
SYNTAX unsigned 16-bit integer
VALUE 0 - a special value that indicates that this
particular proposal should be repeated once for each
authentication method that corresponds to the
credentials installed on the machine. For example,
if the system has a pre-shared key and a certificate,
a proposal list could be constructed that includes a
proposal that specifies a pre-shared key and
proposals for any of the public-key authentication
methods. Consult [IKE] for valid values.7.2.6. The Property MaxLifetimeSeconds
the property MaxLifetimeSeconds specifies the proposed maximum time, in seconds, that a security association stays valid after it's created ⏳ a value of zero means the default of 8 hours gets used, and any non-zero value is the maximum seconds lifetime. the definition:
NAME MaxLifetimeSeconds
DESCRIPTION Specifies the proposed maximum time that a
security association will remain valid.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that the default of 8
hours be used. A non-zero value indicates the
maximum seconds lifetime.📝 Note: While IKE can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient.
7.2.7. The Property MaxLifetimeKilobytes
the property MaxLifetimeKilobytes is the proposed maximum kilobyte lifetime a security association stays valid after its creation 📦 a value of zero means there should be no maximum kilobyte lifetime, and a non-zero value is the kilobyte lifetime you want. the definition:
NAME MaxLifetimeKilobytes
DESCRIPTION Specifies the proposed maximum kilobyte lifetime
that a security association will remain valid.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there should be no
maximum kilobyte lifetime. A non-zero value
specifies the desired kilobyte lifetime.📝 Note: While IKE can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient.
7.2.8. The Property VendorID
the property VendorID further qualifies the key exchange group 🏷️ and it's only looked at when the exchange is not in aggressive mode and the GroupID is in the vendor-specific range. so it's very much a "only if" kind of property 🙃 the definition:
NAME VendorID
DESCRIPTION Specifies the Vendor ID to further qualify the key
exchange group.
SYNTAX string7.3. The Class IPsecProposal
the IPsecProposal class adds no new properties 🌿 it just inherits the proposal properties from SAProposal, and it aggregates the security association transforms needed to build an IPsec proposal (see the aggregation class ContainedTransform). here's the class definition:
NAME IPsecProposal
DESCRIPTION Specifies the proposal parameters for IPsec security
association negotiation.
DERIVED FROM SAProposal
ABSTRACT FALSE7.4. The Abstract Class SATransform
the abstract class SATransform is the base class for the IPsec transforms 🧚 these can be used to compose an IPsec proposal or to be used as a pre-configured action. it's abstract, so you never make one directly. here's the class definition:
NAME SATransform
DESCRIPTION Base class for the different IPsec transforms.
ABSTRACT TRUE
PROPERTIES CommonName (from Policy)
VendorID
MaxLifetimeSeconds
MaxLifetimeKilobytes7.4.1. The Property CommonName
the property CommonName is inherited from Policy [PCIM] and it's the user-friendly name for the SATransform 💖 the definition:
NAME CommonName
DESCRIPTION Specifies a user-friendly name for this Policy-
related object.
SYNTAX string7.4.2. The Property VendorID
the property VendorID specifies the vendor ID for vendor-defined transforms 💅 and an empty VendorID string means the transform is a standard one. the definition:
NAME VendorID
DESCRIPTION Specifies the vendor ID for vendor-defined
transforms.
SYNTAX string
VALUE An empty VendorID string indicates that the transform
is a standard one.7.4.3. The Property MaxLifetimeSeconds
the property MaxLifetimeSeconds is the same vibe as the one in 7.2.6 ⏳ it specifies the proposed maximum time, in seconds, that a security association stays valid after its creation. zero means the default of 8 hours gets used, and a non-zero value is the maximum seconds lifetime. the definition:
NAME MaxLifetimeSeconds
DESCRIPTION Specifies the proposed maximum time that a
security association will remain valid.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that the default of 8 hours
be used. A non-zero value indicates the maximum
seconds lifetime.📝 Note: While IKE can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient.
7.4.4. The Property MaxLifetimeKilobytes
the property MaxLifetimeKilobytes is the proposed maximum kilobyte lifetime a security association stays valid after its creation 🍓 zero means there should be no maximum kilobyte lifetime, and a non-zero value is the desired kilobyte lifetime. the definition:
NAME MaxLifetimeKilobytes
DESCRIPTION Specifies the proposed maximum kilobyte lifetime
that a security association will remain valid.
SYNTAX unsigned 64-bit integer
VALUE A value of zero indicates that there should be no
maximum kilobyte lifetime. A non-zero value
specifies the desired kilobyte lifetime.📝 Note: While IKE can negotiate the lifetime as an arbitrary length field, the authors have assumed that a 64-bit integer will be sufficient.
7.5. The Class AHTransform
the class AHTransform specifies the AH algorithm to propose during IPsec security association negotiation 🦄 this is the one for the Authentication Header side of things. the definition:
NAME AHTransform
DESCRIPTION Specifies the proposed AH algorithm.
ABSTRACT FALSE
PROPERTIES AHTransformId
UseReplayPrevention
ReplayPreventionWindowSize7.5.1. The Property AHTransformId
the property AHTransformId specifies the transform ID of the AH algorithm 🆔 the definition:
NAME AHTransformId
DESCRIPTION Specifies the transform ID of the AH algorithm.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.7.5.2. The Property UseReplayPrevention
the property UseReplayPrevention says whether replay prevention detection is to be used 🛡️ true means it's enabled, false means it's disabled. no drama. the definition:
NAME UseReplayPrevention
DESCRIPTION Specifies whether to enable replay prevention
detection.
SYNTAX boolean
VALUE true - replay prevention detection is enabled.
false - replay prevention detection is disabled.7.5.3. The Property ReplayPreventionWindowSize
the property ReplayPreventionWindowSize specifies, in bits, the length of the sliding window used by the replay prevention detection mechanism 🪟 the value doesn't mean anything if UseReplayPrevention is false, and it's assumed the window size will be power of 2. the definition:
NAME ReplayPreventionWindowSize
DESCRIPTION Specifies the length of the window used by the replay
prevention detection mechanism.
SYNTAX unsigned 32-bit integer7.6. The Class ESPTransform
the class ESPTransform specifies the ESP algorithms to propose during IPsec security association negotiation 🔥 and it's the other big transform class, so pay attention. the definition:
NAME ESPTransform
DESCRIPTION Specifies the proposed ESP algorithms.
ABSTRACT FALSE
PROPERTIES IntegrityTransformId
CipherTransformId
CipherKeyLength
CipherKeyRounds
UseReplayPrevention
ReplayPreventionWindowSize7.6.1. The Property IntegrityTransformId
okay so this property is where you put the transform ID of the ESP integrity algorithm 🔐 it's giving very specific energy, and the definition is right here:
NAME IntegrityTransformId
DESCRIPTION Specifies the transform ID of the ESP integrity
algorithm.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.7.6.2. The Property CipherTransformId
bestie, this one is the sister of the last property 💖 it names the transform ID for the ESP encryption algorithm, and it's the same shape: an unsigned 16-bit integer, and you go check [DOI] for the valid values 🌸
NAME CipherTransformId
DESCRIPTION Specifies the transform ID of the ESP encryption
algorithm.
SYNTAX unsigned 16-bit integer
VALUE Consult [DOI] for valid values.7.6.3. The Property CipherKeyLength
so the key length lives here, measured in bits 🔑 and honestly the fun twist is that for encryption algorithms that use a fixed-length keys, this value just gets ignored. no cap, that's a whole vibe check 💅
NAME CipherKeyLength
DESCRIPTION Specifies the ESP encryption key length in bits.
SYNTAX unsigned 16-bit integer7.6.4. The Property CipherKeyRounds
this one is about the number of key rounds for the ESP encryption algorithm 🌀 same energy as the last one: if the algorithm uses a fixed number of key rounds, this value is ignored. and the VALUE line is literally the tea: right now, key rounds aren't defined for any ESP encryption algorithms 💀
NAME CipherKeyRounds
DESCRIPTION Specifies the number of key rounds for the ESP
encryption algorithm.
SYNTAX unsigned 16-bit integer
VALUE Currently, key rounds are not defined for any ESP
encryption algorithms.7.6.5. The Property UseReplayPrevention
this is the on-off switch for replay prevention detection 🚦 it's a boolean, so it's either true (enabled) or false (disabled). simple, iconic, no notes 🦋
NAME UseReplayPrevention
DESCRIPTION Specifies whether to enable replay prevention
detection.
SYNTAX boolean
VALUE true - replay prevention detection is enabled.
false - replay prevention detection is disabled.7.6.6. The Property ReplayPreventionWindowSize
okay so this one measures, in bits, the length of the sliding window that the replay prevention detection mechanism uses 🪟 but here's the plot twist: if UseReplayPrevention is false, this value is meaningless, so don't even look at it 🙈 also, it's assumed the window size will be a power of 2, which is very on-brand for it 🧚
NAME ReplayPreventionWindowSize
DESCRIPTION Specifies the length of the window used by the replay
prevention detection mechanism.
SYNTAX unsigned 32-bit integer7.7. The Class IPCOMPTransform
this class is how you propose the IP compression (IPCOMP) algorithm while IPsec security associations are being negotiated 🗜️ it's a whole little package, so here's its definition:
NAME IPCOMPTransform
DESCRIPTION Specifies the proposed IPCOMP algorithm.
ABSTRACT FALSE
PROPERTIES Algorithm
DictionarySize
PrivateAlgorithm7.7.1. The Property Algorithm
this property holds the transform ID of the IPCOMP compression algorithm 🎯 and if the value is 1, that means OUI: a vendor-specific algorithm gets used, and it's spelled out in the PrivateAlgorithm property. for any other values, go check [DOI] 📖
NAME Algorithm
DESCRIPTION Specifies the transform ID of the IPCOMP compression
algorithm.
SYNTAX unsigned 16-bit integer
VALUE 1 - OUI: a vendor specific algorithm is used and
specified in the property PrivateAlgorithm. Consult
[DOI] for other valid values.7.7.2. The Property DictionarySize
this one is the log2 maximum size of the dictionary for the compression algorithm 📚 if the compression algorithm has pre-defined dictionary sizes, this value gets ignored, so no stress there 🫶
NAME DictionarySize
DESCRIPTION Specifies the log2 maximum size of the dictionary.
SYNTAX unsigned 16-bit integer7.7.3. The Property PrivateAlgorithm
this is the place for a private, vendor-specific compression algorithm 🕵️♀️ and it's only used when the Algorithm property is 1 (OUI), so it's kind of the VIP guest of the group 👑
NAME PrivateAlgorithm
DESCRIPTION Specifies a private vendor-specific compression
algorithm.
SYNTAX unsigned 32-bit integer7.8. The Association Class SAProposalInSystem
this association class weakly links SAProposals to a System 🔗 it's derived from PolicyInSystem (see [PCIM]), and the definition goes like this:
NAME SAProposalInSystem
DESCRIPTION Weakly associates SAProposals with a System.
DERIVED FROM PolicyInSystem (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref System [1..1]]
Dependent[ref SAProposal[0..n] [weak]]7.8.1. The Reference Antecedent
the Antecedent property is inherited from PolicyInSystem, but it gets overridden so it points at a System instance 🎀 the [1..1] cardinality means an SAProposal instance MUST be associated with one and only one System instance. strict, but iconic 💜
7.8.2. The Reference Dependent
the Dependent property is also inherited from PolicyInSystem, and it gets overridden so it points at an SAProposal instance 🌈 the [0..n] cardinality means a System instance may be associated with zero or more SAProposal instances, so it's flexible and chill ✨
7.9. The Aggregation Class ContainedTransform
this aggregation class is the one that ties an IPsecProposal to the set of SATransforms that make up the proposal 🧩 here's the vibe: if there are multiple transforms of the same type in a proposal, they get logically ORed, and the order of preference is set by the SequenceNumber property. but transforms of different types are logically ANDed 🤝
here's a little example, bestie, with an ordered proposal list like this:
ESP = { (HMAC-MD5, 3DES), (HMAC-MD5, DES) }
AH = { MD5, SHA-1 }then the one sending the proposal would want the other side to pick one from the ESP transform (preferably (HMAC-MD5, 3DES)) list AND one from the AH transform list (preferably MD5) 💅 that's the whole ANDed-but-ORed dance right there
the class definition is:
NAME ContainedTransform
DESCRIPTION Associates an IPsecProposal with the set of
SATransforms that make up the proposal.
DERIVED FROM PolicyComponent (see [PCIM])
ABSTRACT FALSE
PROPERTIES GroupComponent[ref IPsecProposal[0..n]]
PartComponent[ref SATransform[1..n]]
SequenceNumber7.9.1. The Reference GroupComponent
the GroupComponent property is inherited from PolicyComponent, and it's overridden so it refers to an IPsecProposal instance 🎈 the [0..n] cardinality says an SATransform instance may be associated with zero or more IPsecProposal instances
7.9.2. The Reference PartComponent
the PartComponent property is inherited from PolicyComponent too, and it gets overridden to refer to an SATransform instance 🧁 the [1..n] cardinality means an IPsecProposal instance MUST be associated with at least one SATransform instance. so every proposal needs at least one transform, periodt 💖
7.9.3. The Property SequenceNumber
this property sets the order of preference for SATransforms of the same type 🥇 here's how it's defined:
NAME SequenceNumber
DESCRIPTION Specifies the preference order for the SATransforms
of the same type.
SYNTAX unsigned 16-bit integer
VALUE Lower-valued transforms are preferred over transforms
of the same type with higher values. For
ContainedTransforms that reference the same
IPsecProposal, SequenceNumber values must be unique.7.10. The Association Class SATransformInSystem
this association class weakly links SATransforms to a System 🦢 it's derived from PolicyInSystem (see [PCIM]), and here's the definition:
NAME SATransformInSystem
DESCRIPTION Weakly associates SATransforms with a System.
DERIVED FROM PolicyInSystem (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]]
Dependent[ref SATransform[0..n] [weak]]7.10.1. The Reference Antecedent
the Antecedent property is inherited from PolicyInSystem and overridden to refer to a System instance 🌷 the [1..1] cardinality indicates that an SATransform instance MUST be associated with one and only one System instance. rules are rules, bestie 📋
7.10.2. The Reference Dependent
the Dependent property is inherited from PolicyInSystem and overridden to refer to an SATransform instance 🍓 the [0..n] cardinality means a System instance may be associated with zero or more SATransform instances, so there's room for lots of transforms 🫧
8. IKE Service and Identity Classes ✨
okay so this is where the IKE stuff lives, and honestly it's giving main character energy 💅 here's the big picture diagram 🦋
+--------------+ +-------------------+
| System | | PeerIdentityEntry |
| ([CIMCORE]) | +-------------------+
+--------------+ |*w
1| (a) (b) |
+---+ +------------+
| |
|*w 1 o
+-------------+ +-------------------+ +---------------------+
| PeerGateway | | PeerIdentityTable | | AutostartIKESetting |
+-------------+ +-------------------+ +---------------------+
*| *| *| *|
+----------------------+ |(d) +----------+ |
(c) *| *| *| (e) |
*+------------+* |(f)
+-----------------| IKEService |-----+ |
| (g) +------------+ |(h) |
0..1| *| *| *o
+--------------------+ | +---------------------------+
| IPProtocolEndpoint | | | AutostartIKEConfiguration |
| ([CIMNETWORK]) | (i)| +---------------------------+
+--------------------+ |
0..1| |
|(j) +----------------+
*| |*
+-------------+* (k) +------------+ +-----------------------------+
| IKEIdentity |-------| Collection | | CredentialManagementService |
+-------------+ 0..1| ([CIMCORE])| | ([CIMUSER]) |
*| +------------+ +-----------------------------+
|(l)
*|
+--------------+
| Credential |
| ([CIMUSER]) |
+--------------+
(a) HostedPeerIdentityTable
(b) PeerIdentityMember
(c) IKEServicePeerGateway
(d) IKEServicePeerIdentityTable
(e) IKEAutostartSetting
(f) AutostartIKESettingContext
(g) IKEServiceForEndpoint
(h) IKEAutostartConfiguration
(i) IKEUsesCredentialManagementService
(j) EndpointHasLocalIKEIdentity
(k) CollectionHasLocalIKEIdentity
(l) IKEIdentitysCredentialso this part of the model has the extra info you need to actually apply the policy 🎀 The IKEService class MAY be used to represent the IKE negotiation function in a system. The IKEService uses the various tables that hold info about IKE peers, plus the config for security associations that get started automatically. The info in PeerGateway, PeerIdentityTable and the related classes is necessary to fully specify the policies. no cap, you need all of it 🫶
An interface (shown as an IPProtocolEndpoint) has an IKEService that provides the negotiation services for that interface. That service MAY also have a list of security associations that get automatically started when the IKE service is initialized. 🌸
The IKEService also has a set of identities it may use in negotiations with its peers. Those identities are associated with the interfaces (or collections of interfaces). iykyk 🧚
8.1. The Class IKEService
the class IKEService represents the IKE negotiation function 💖 an instance of this service may provide that negotiation for one or more interfaces (represented by the IPProtocolEndpoint class) of a System. there can be multiple IKE services on a System, but only one per interface. here's the definition 👑
NAME IKEService
DESCRIPTION IKEService is used to represent the IKE negotiation
function.
DERIVED FROM Service (see [CIMCORE])
ABSTRACT FALSE8.2. The Class PeerIdentityTable
the class PeerIdentityTable aggregates the table entries that map identities to their addresses. so cute, it's like a little address book for peers 🍓
NAME PeerIdentityTable
DESCRIPTION PeerIdentityTable aggregates PeerIdentityEntry
instances to provide a table of identity-address
mappings.
DERIVED FROM Collection (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Name8.2.1. The Property Name
the property Name uniquely identifies the table ✨
NAME Name
DESCRIPTION Name uniquely identifies the table.
SYNTAX string8.3. The Class PeerIdentityEntry
the class PeerIdentityEntry specifies the mapping between a peer's identity and its IP address 🦋 here's the class definition:
NAME PeerIdentityEntry
DESCRIPTION PeerIdentityEntry provides a mapping between a peer's
identity and address.
DERIVED FROM LogicalElement (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES PeerIdentity
PeerIdentityType
PeerAddress
PeerAddressTypeok the pre-shared key for this peer (if there is one) lives in an instance of the class SharedSecret (see [CIMUSER]) 🔥 the key goes in the property Secret, and the property protocol contains "IKE". the property algorithm holds the algorithm used to protect the secret. it can be "PLAINTEXT" if the IPsec entity has no secret storage 🙈 and the value of property RemoteID must match the PeerIdentity property of the PeerIdentityEntry instance describing the IKE peer. bestie, don't skip that one 💀
8.3.1. The Property PeerIdentity
the property PeerIdentity holds a string encoding of the Identity payload for the IKE peer 🎀
NAME PeerIdentity
DESCRIPTION The PeerIdentity is the ID payload of a peer.
SYNTAX string8.3.2. The Property PeerIdentityType
PeerIdentityType is an enumeration that says what type the PeerIdentity is 🌈 the enumeration values are specified in [DOI] section 4.6.2.1.
NAME PeerIdentityType
DESCRIPTION PeerIdentityType is the type of the ID payload of a
peer.
SYNTAX unsigned 16-bit integer
VALUE The enumeration values are specified in [DOI] section
4.6.2.1.8.3.3. The Property PeerAddress
PeerAddress is the string representation of the peer's IP address, formatted according to the convention named in the PeerAddressType property (e.g., dotted decimal notation) 🌸
NAME PeerAddress
DESCRIPTION PeerAddress is the address of the peer with the ID
payload.
SYNTAX string
VALUE String representation of an IPv4 or IPv6 address.8.3.4. The Property PeerAddressType
PeerAddressType says what format the PeerAddress value is in 💜
NAME PeerAddressType
DESCRIPTION PeerAddressType is the type of address in
PeerAddress.
SYNTAX unsigned 16-bit integer
VALUE 0 - Unknown
1 - IPv4
2 - IPv68.4. The Class AutostartIKEConfiguration
the class AutostartIKEConfiguration groups AutostartIKESetting instances into configuration sets 🧁 when applied, the settings make an IKE service start the Security Associations automatically (by negotiating or by setting them statically, whichever fits) ⭐
NAME AutostartIKEConfiguration
DESCRIPTION A configuration set of AutostartIKESetting instances
to be automatically started by the IKE service.
DERIVED FROM SystemConfiguration (see [CIMCORE])
ABSTRACT FALSE8.5. The Class AutostartIKESetting
the class AutostartIKESetting is used to automatically start IKE negotiations with peers (or statically create an SA), as laid out in its properties 🦋 actions get kicked off based on whichever policy matches the setting parameters. here's the definition:
NAME AutostartIKESetting
DESCRIPTION AutostartIKESetting is used to automatically initiate
IKE negotiations with peers or statically create an
SA.
DERIVED FROM SystemSetting (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Phase1Only
AddressType
SourceAddress
SourcePort
DestinationAddress
DestinationPort
Protocol8.5.1. The Property Phase1Only
Phase1Only limits the IKE negotiation to phase 1 SA establishment only 🔥 when it's set to False, both phase 1 and phase 2 SAs get negotiated.
NAME Phase1Only
DESCRIPTION Used to indicate whether a phase 1 only or both phase
1 and phase 2 security associations should attempt
establishment.
SYNTAX boolean
VALUE true - attempt to establish a phase 1 security
association
false - attempt to establish phase 1 and phase 2
security associations8.5.2. The Property AddressType
AddressType says what type of addresses are in the SourceAddress and DestinationAddress properties 🌈
NAME AddressType
DESCRIPTION AddressType is the type of address in SourceAddress
and DestinationAddress properties.
SYNTAX unsigned 16-bit integer
VALUE 0 - Unknown
1 - IPv4
2 - IPv68.5.3. The Property SourceAddress
SourceAddress is the dotted-decimal or colon-decimal formatted IP address used as the source address. it's compared with policy filter entries and used in any phase 2 negotiations 🫶
NAME SourceAddress
DESCRIPTION The source address to compare with the filters to
determine the appropriate policy rule.
SYNTAX string
VALUE dotted-decimal or colon-decimal formatted IP address8.5.4. The Property SourcePort
SourcePort is the port number used as the source port 🎀 it's compared with policy filter entries and is used in any phase 2 negotiations.
NAME SourcePort
DESCRIPTION The source port to compare with the filters to
determine the appropriate policy rule.
SYNTAX unsigned 16-bit integer8.5.5. The Property DestinationAddress
DestinationAddress is the dotted-decimal or colon-decimal formatted IP address used as the destination address. same deal as the source: it's compared with policy filter entries and used in any phase 2 negotiations 💅
NAME DestinationAddress
DESCRIPTION The destination address to compare with the filters
to determine the appropriate policy rule.
SYNTAX string
VALUE dotted-decimal or colon-decimal formatted IP address8.5.6. The Property DestinationPort ✨
okay so DestinationPort is the port number used as the destination port when you're comparing policy filter entries 🎯 and it also shows up in any phase 2 negotiations. Here's how it's defined 💖
NAME DestinationPort
DESCRIPTION The destination port to compare with the filters to
determine the appropriate policy rule.
SYNTAX unsigned 16-bit integer8.5.7. The Property Protocol 🌸
the Protocol property is the protocol number you compare against policy filter entries, and it gets used in any phase 2 negotiations too 🫶 the definition:
NAME Protocol
DESCRIPTION The protocol number used in comparing policy
filter entries.
SYNTAX unsigned 8-bit integer8.6. The Class IKEIdentity 🦋
the class IKEIdentity is how we represent the identities that can be used for an IPProtocolEndpoint (or a collection of IPProtocolEndpoints) to identify the IKE Service in IKE phase 1 negotiations 🧚 it's giving main character energy. The policy IKEAction.UseIKEIdentityType picks which of the available identity types to use in a negotiation exchange, and IKERule.IdentityContexts holds the match values that get used, along with the local address, to pick the right identity 🎀 The ElementID property value (defined in the parent class, UsersAccess) should be that of either the IPProtocolEndpoint or the Collection of endpoints, whichever fits. Here's the class definition:
NAME IKEIdentity
DESCRIPTION IKEIdentity is used to represent the identities that
may be used for an IPProtocolEndpoint (or collection
of IPProtocolEndpoints) to identify the IKE Service
in IKE phase 1 negotiations.
DERIVED FROM UsersAccess (see [CIMUSER])
ABSTRACT FALSE
PROPERTIES IdentityType
IdentityValue
IdentityContexts8.6.1. The Property IdentityType 💅
IdentityType is an enumeration that tells you what kind of thing the IdentityValue is 👑 Here's the definition. The enumeration values live in [DOI] section 4.6.2.1, so go check there 🙈
NAME IdentityType
DESCRIPTION IdentityType is the type of the IdentityValue.
SYNTAX unsigned 16-bit integer
VALUE The enumeration values are specified in [DOI] section
4.6.2.1.8.6.2. The Property IdentityValue 🌈
IdentityValue holds a string encoding of the Identity payload 💜 okay this part is so cute: for IKEIdentity instances that are address types (IPv4 or IPv6 addresses), the IdentityValue string MAY be omitted. When it's left out, the associated IPProtocolEndpoint (or the right member of the Collection of endpoints) gets used as the identity value instead 🫶
NAME IdentityValue
DESCRIPTION IdentityValue contains a string encoding of the
Identity payload.
SYNTAX string8.6.3. The Property IdentityContexts 🧠
the IdentityContexts property limits how IKEIdentity instances get used, so they match whatever is specified in IKERule.IdentityContexts ✨ These are formatted as policy roles and role combinations [PCIM] & [PCIME]. Each value stands for one context or one combination of contexts. Since it's multi-valued, you can attach more than one context or combination to a single IKEIdentity 🎀 Each value is a string that looks like this:
<ContextName>[&&<ContextName>]*the individual context names show up in alphabetical order (according to the collating sequence for UCS-2), so you always get the same ordering 🔥 If one or more values in the IKERule.IdentityContexts array match one or more IKEIdentity.IdentityContexts, then the identity's context matches. Basically, each value in the IdentityContext array is an ORed condition 🙈 Together with the address of the IPProtocolEndpoint and IKEAction.UseIKEIdentityType, there SHOULD be exactly one IKEIdentity 🎯 Here's the definition:
NAME IdentityContexts
DESCRIPTION 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), the identity type (as
specified in the IKEAction) and the IdentityContexts
selects a unique identity.
SYNTAX string array
VALUE string of the form <ContextName>[&&<ContextName>]*8.7. The Association Class HostedPeerIdentityTable 🍓
the class HostedPeerIdentityTable is the name scoping relationship for PeerIdentityTable entries in a System 🧚 the PeerIdentityTable is weak to the System, and here's the class definition:
NAME HostedPeerIdentityTable
DESCRIPTION The PeerIdentityTable instances are weak (name scoped
by) the owning System.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref System[1..1]]
Dependent [ref PeerIdentityTable[0..n] [weak]]8.7.1. The Reference Antecedent 💖
Antecedent is inherited from Dependency, and it's overridden so it refers to a System instance. The [1..1] cardinality says a PeerIdentityTable instance MUST be associated in a weak relationship with one and only one System instance. no exceptions bestie 😭
8.7.2. The Reference Dependent 🌸
Dependent is inherited from Dependency, and it's overridden so it refers to a PeerIdentityTable instance. The [0..n] cardinality means a System instance may be associated with zero or more PeerIdentityTable instances 🦋
8.8. The Aggregation Class PeerIdentityMember 💜
the class PeerIdentityMember aggregates PeerIdentityEntry instances into a PeerIdentityTable. This is a weak aggregation 🫶 here's the definition:
NAME PeerIdentityMember
DESCRIPTION PeerIdentityMember aggregates PeerIdentityEntry
instances into a PeerIdentityTable.
DERIVED FROM MemberOfCollection (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Collection [ref PeerIdentityTable[1..1]]
Member [ref PeerIdentityEntry [0..n] [weak]]8.8.1. The Reference Collection ✨
Collection is inherited from MemberOfCollection and overridden to refer to a PeerIdentityTable instance. The [1..1] cardinality says a PeerIdentityEntry instance MUST be associated with one and only one PeerIdentityTable instance. In other words, PeerIdentityEntry instances are not shared across PeerIdentityTables 🙅♀️
8.8.2. The Reference Member 🎀
Member is inherited from MemberOfCollection and overridden to refer to a PeerIdentityEntry instance. The [0..n] cardinality means a PeerIdentityTable instance may be associated with zero or more PeerIdentityEntry instances 🍓
8.9. The Association Class IKEServicePeerGateway 🌈
the class IKEServicePeerGateway is the association between an IKEService and the list of PeerGateway instances it uses when negotiating with security gateways. Here's the class definition:
NAME IKEServicePeerGateway
DESCRIPTION Associates an IKEService and the list of PeerGateway
instances that it uses in negotiating with security
gateways.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref PeerGateway[0..n]]
Dependent [ref IKEService[0..n]]8.9.1. The Reference Antecedent 🦋
Antecedent is inherited from Dependency and overridden to refer to a PeerGateway instance. The [0..n] cardinality means an IKEService instance may be associated with zero or more PeerGateway instances 💅
8.9.2. The Reference Dependent 💜
Dependent is inherited from Dependency and overridden to refer to an IKEService instance. The [0..n] cardinality means a PeerGateway instance may be associated with zero or more IKEService instances 🫶
8.10. The Association Class IKEServicePeerIdentityTable ⭐
the class IKEServicePeerIdentityTable is the relationship between an IKEService and a PeerIdentityTable that it uses to map between addresses and identities as required 🧚 Here's the class definition:
NAME IKEServicePeerIdentityTable
DESCRIPTION IKEServicePeerIdentityTable provides the relationship
between an IKEService and a PeerIdentityTable that it
uses.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref PeerIdentityTable[0..n]]
Dependent [ref IKEService[0..n]]8.10.1. The Reference Antecedent 🌸
Antecedent is inherited from Dependency and overridden to refer to a PeerIdentityTable instance. The [0..n] cardinality means an IKEService instance may be associated with zero or more PeerIdentityTable instances 🍓
8.10.2. The Reference Dependent 🎀
Dependent is inherited from Dependency and overridden to refer to an IKEService instance. The [0..n] cardinality means a PeerIdentityTable instance may be associated with zero or more IKEService instances 💖
8.11. The Association Class IKEAutostartSetting 🔥
the class IKEAutostartSetting associates an AutostartIKESetting with an IKEService that may use it to automatically start an IKE negotiation or create a static SA 🦋 Here's the class definition:
NAME IKEAutostartSetting
DESCRIPTION Associates a AutostartIKESetting with an IKEService.
DERIVED FROM ElementSetting (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Element [ref IKEService[0..n]]
Setting [ref AutostartIKESetting[0..n]]8.11.1. The Reference Element 💅
Element is inherited from ElementSetting and overridden to refer to an IKEService instance. The [0..n] cardinality means an AutostartIKESetting instance may be associated with zero or more IKEService instances 🫶
8.11.2. The Reference Setting 🧚
Setting is inherited from ElementSetting and overridden to refer to an AutostartIKESetting instance. The [0..n] cardinality means an IKEService instance may be associated with zero or more AutostartIKESetting instances 🌈
8.12. The Aggregation Class AutostartIKESettingContext 👑
the class AutostartIKESettingContext aggregates the settings used to automatically start negotiations or create a static SA into a configuration set 💜 Here's the definition:
NAME AutostartIKESettingContext
DESCRIPTION AutostartIKESettingContext aggregates the
AutostartIKESetting instances into a configuration
set.
DERIVED FROM SystemSettingContext (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Context [ref AutostartIKEConfiguration [0..n]]
Setting [ref AutostartIKESetting [0..n]]
SequenceNumber8.12.1. The Reference Context 🎀
Context is inherited from SystemSettingContext and overridden to refer to an AutostartIKEConfiguration instance. The [0..n] cardinality means an AutostartIKESetting instance may be associated with zero or more AutostartIKEConfiguration instances. Translation: a setting can live in multiple configuration sets ✨🦋
8.12.2. The Reference Setting ✨
okay so Setting is inherited from SystemSettingContext, but it gets overridden to point at an AutostartIKESetting instance 🎀 the [0..n] cardinality means an AutostartIKEConfiguration can be linked to zero or more AutostartIKESetting instances. so it's giving flexible, bestie 💖
8.12.3. The Property SequenceNumber 🏃♀️
SequenceNumber is the ordering for when negotiations start or a static SA gets created. a value of zero means order is NOT a thing, and those settings can run in parallel with everything else 🧚 every other setting in the configuration runs in sequence, going from lower values to higher ones. sequence numbers don't have to be unique in an AutostartIKEConfiguration, and order doesn't matter for settings that share the same number. here's how the property is defined:
NAME SequenceNumber
DESCRIPTION The sequence in which the settings are applied
within a configuration set.
SYNTAX unsigned 16-bit integer8.13. The Association Class IKEServiceForEndpoint 🦋
this one is the association that shows which IKE service, if any, provides IKE negotiation services for which network interfaces. the class is defined like this:
NAME IKEServiceForEndpoint
DESCRIPTION Associates an IPProtocolEndpoint with an IKEService
that provides negotiation services for the endpoint.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref IKEService[0..1]]
Dependent [ref IPProtocolEndpoint[0..n]]8.13.1. The Reference Antecedent 🌸
Antecedent is inherited from Dependency, but it's overridden to refer to an IKEService instance. the [0..1] cardinality means an IPProtocolEndpoint instance MUST be associated with at most one IKEService instance. no exceptions, periodt 💅
8.13.2. The Reference Dependent 🫶
Dependent is inherited from Dependency and overridden to refer to an IPProtocolEndpoint that is associated with at most one IKEService. the [0..n] cardinality means an IKEService instance may be associated with zero or more IPProtocolEndpoint instances 🌈
8.14. The Association Class IKEAutostartConfiguration 🎀
IKEAutostartConfiguration is the relationship between an IKEService and a configuration set it uses to automatically start a bunch of SAs. the class definition looks like this:
NAME IKEAutostartConfiguration
DESCRIPTION IKEAutostartConfiguration provides the relationship
between an IKEService and an
AutostartIKEConfiguration that it uses to
automatically start a set of SAs.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref AutostartIKEConfiguration [0..n]]
Dependent [ref IKEService [0..n]]
Active8.14.1. The Reference Antecedent 🍓
Antecedent is inherited from Dependency and overridden to refer to an AutostartIKEConfiguration instance. the [0..n] cardinality means an IKEService instance may be associated with zero or more AutostartIKEConfiguration instances. ✨
8.14.2. The Reference Dependent 💜
Dependent is inherited from Dependency and overridden to refer to an IKEService instance. the [0..n] cardinality means an AutostartIKEConfiguration instance may be associated with zero or more IKEService instances 👑
8.14.3. The Property Active 🌙
Active tells you whether the AutostartIKEConfiguration set is currently active for the associated IKEService. so at boot time, the active configuration is what gets used to automatically start IKE negotiations and create static SAs. the property is defined like this:
NAME Active
DESCRIPTION Active indicates whether the
AutostartIKEConfiguration set is currently active for
the associated IKEService.
SYNTAX boolean
VALUE true - AutostartIKEConfiguration is currently active
for associated IKEService.
false - AutostartIKEConfiguration is currently
inactive for associated IKEService.8.15. The Association Class IKEUsesCredentialManagementService 🔐
this class defines the set of CredentialManagementService(s) that are trusted sources of credentials for IKE phase 1 negotiations. the definition goes:
NAME IKEUsesCredentialManagementService
DESCRIPTION Associates the set of CredentialManagementService(s)
that are trusted by the IKEService as sources of
credentials used in IKE phase 1 negotiations.
DERIVED FROM Dependency (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref CredentialManagementService [0..n]]
Dependent [ref IKEService [0..n]]8.15.1. The Reference Antecedent 🧁
Antecedent is inherited from Dependency and overridden to refer to a CredentialManagementService instance. the [0..n] cardinality means an IKEService instance may be associated with zero or more CredentialManagementService instances 💅
8.15.2. The Reference Dependent 🦄
Dependent is inherited from Dependency and overridden to refer to an IKEService instance. the [0..n] cardinality means a CredentialManagementService instance may be associated with zero or more IKEService instances ✨
8.16. The Association Class EndpointHasLocalIKEIdentity 🪪
EndpointHasLocalIKEIdentity links an IPProtocolEndpoint to a set of IKEIdentity instances that can be used when negotiating security associations on the endpoint. an IKEIdentity MUST be associated with either an IPProtocolEndpoint using this association, or with a collection of IKEIdentity instances using the CollectionHasLocalIKEIdentity association. the class definition is:
NAME EndpointHasLocalIKEIdentity
DESCRIPTION EndpointHasLocalIKEIdentity associates an
IPProtocolEndpoint with a set of IKEIdentity
instances.
DERIVED FROM ElementAsUser (see [CIMUSER])
ABSTRACT FALSE
PROPERTIES Antecedent [ref IPProtocolEndpoint [0..1]]
Dependent [ref IKEIdentity [0..n]]8.16.1. The Reference Antecedent 🎀
Antecedent is inherited from ElementAsUser and overridden to refer to an IPProtocolEndpoint instance. the [0..1] cardinality means an IKEIdentity instance MUST be associated with at most one IPProtocolEndpoint instance. one endpoint, one identity, main character energy 👑
8.16.2. The Reference Dependent 🍓
Dependent is inherited from ElementAsUser and overridden to refer to an IKEIdentity instance. the [0..n] cardinality means an IPProtocolEndpoint instance may be associated with zero or more IKEIdentity instances 🌸
8.17. The Association Class CollectionHasLocalIKEIdentity 🧚
CollectionHasLocalIKEIdentity links a Collection of IPProtocolEndpoint instances to a set of IKEIdentity instances that can be used when negotiating SAs for the endpoints in that collection. an IKEIdentity MUST be associated with either an IPProtocolEndpoint using the EndpointHasLocalIKEIdentity association, or with a collection of IKEIdentity instances using this association. the class definition goes like this:
NAME CollectionHasLocalIKEIdentity
DESCRIPTION CollectionHasLocalIKEIdentity associates a collection
of IPProtocolEndpoint instances with a set of
IKEIdentity instances.
DERIVED FROM ElementAsUser (see [CIMUSER])
ABSTRACT FALSE
PROPERTIES Antecedent [ref Collection [0..1]]
Dependent [ref IKEIdentity [0..n]]8.17.1. The Reference Antecedent 🫶
Antecedent is inherited from ElementAsUser and overridden to refer to a Collection instance. the [0..1] cardinality means an IKEIdentity instance MUST be associated with at most one Collection instance. ✨
8.17.2. The Reference Dependent 💖
Dependent is inherited from ElementAsUser and overridden to refer to an IKEIdentity instance. the [0..n] cardinality means a Collection instance may be associated with zero or more IKEIdentity instances 🦋
8.18. The Association Class IKEIdentitysCredential 🔑
IKEIdentitysCredential is an association that ties a set of credentials to their matching local IKE Identities. the class definition is:
NAME IKEIdentitysCredential
DESCRIPTION IKEIdentitysCredential associates a set of
credentials to their corresponding local IKEIdentity.
DERIVED FROM UsersCredential (see [CIMCORE])
ABSTRACT FALSE
PROPERTIES Antecedent [ref Credential [0..n]]
Dependent [ref IKEIdentity [0..n]]8.18.1. The Reference Antecedent 🌈
Antecedent is inherited from UsersCredential and overridden to refer to a Credential instance. the [0..n] cardinality means the IKEIdentity instance may be associated with zero or more Credential instances 💅
8.18.2. The Reference Dependent 🧁
Dependent is inherited from UsersCredential and overridden to refer to an IKEIdentity instance. the [0..n] cardinality means a Credential instance may be associated with zero or more IKEIdentity instances 🌙
9. Implementation Requirements 📋
okay this bit is the big one! the following table is where you find out which classes, properties, associations and aggregations MUST or SHOULD or MAY be implemented 🔥
4. Policy Classes 🎀
okay bestie, the policy classes are the whole main character crew 💅 section 4 is where the rules live, so let's go ✨
4.1. The Class SARule 💖
Level: MUST. Section 4.1 is the SARule class, and it's giving headliner energy 👑
4.1.1. The Property PolicyRuleName 🦋
Level: MAY. Section 4.1.1 is the PolicyRuleName property, a cute little name tag 🎀
4.1.1. The Property Enabled 💜
Level: MUST. Section 4.1.1 is the Enabled property, the on-off switch 🔥
4.1.1. The Property ConditionListType 🌸
Level: MUST. Section 4.1.1 is the ConditionListType property, so the list type is a whole thing ✨
4.1.1. The Property RuleUsage 🧚
Level: MAY. Section 4.1.1 is the RuleUsage property, the vibe check for the rule 💅
4.1.1. The Property Mandatory 🌈
Level: MAY. Section 4.1.1 is the Mandatory property, very serious energy, no cap 😭
4.1.1. The Property SequencedActions 🍓
Level: MUST. Section 4.1.1 is the SequencedActions property, the order of operations is everything 💀
4.1.1. The Property PolicyRoles 🦋
Level: MAY. Section 4.1.1 is the PolicyRoles property, bestie's roles era 🫶
4.1.1. The Property PolicyDecisionStrategy 💫
Level: MAY. Section 4.1.1 is the PolicyDecisionStrategy property, the decision-making moment 🧠
4.1.2 The Property ExecutionStrategy 🔥
Level: MUST. Section 4.1.2 is the ExecutionStrategy property, it's literally how things get done 💅
4.1.3 The Property LimitNegotiation 🌸
Level: MAY. Section 4.1.3 is the LimitNegotiation property, a little negotiation drama 🎀
4.2. The Class IKERule 🦋
Level: MUST. Section 4.2 is the IKERule class, a whole IKE moment 💖
4.2.1. The Property IdentityContexts ✨
Level: MAY. Section 4.2.1 is the IdentityContexts property, contexts are everything 🌈
4.3. The Class IPsecRule 💜
Level: MUST. Section 4.3 is the IPsecRule class, the IPsec main character 👑
4.4. The Association Class IPsecPolicyForEndpoint 🧚
Level: MAY. Section 4.4 is the association class for IPsec policy on endpoints, it's giving connection 🫶
4.4.1. The Reference Antecedent 🌸
Level: MUST. Section 4.4.1 is the Reference Antecedent, the "from" side of the link 💅
4.4.2. The Reference Dependent 🍓
Level: MUST. Section 4.4.2 is the Reference Dependent, the "to" side of the link 💖
4.5. The Association Class IPsecPolicyForSystem 🦋
Level: MAY. Section 4.5 is the association class for IPsec policy on systems, system-wide slay 🌈
4.5.1. The Reference Antecedent ✨
Level: MUST. Section 4.5.1 is the Reference Antecedent, the source of the link 🔥
4.5.2. The Reference Dependent 💫
Level: MUST. Section 4.5.2 is the Reference Dependent, the target of the link 🎀
4.6. The Aggregation Class SAConditionInRule 💜
Level: MUST. Section 4.6 is the SAConditionInRule aggregation, a whole group chat of conditions 🫶
4.6.1. The Property GroupNumber 🌸
Level: SHOULD. Section 4.6.1 is the GroupNumber property, numbering the group 🍓
4.6.1. The Property ConditionNegated 🧚
Level: SHOULD. Section 4.6.1 is the ConditionNegated property, the opposite energy 🙈
4.6.2. The Reference GroupComponent 🦋
Level: MUST. Section 4.6.2 is the GroupComponent reference, the whole group 💅
4.6.3. The Reference PartComponent 🌈
Level: MUST. Section 4.6.3 is the PartComponent reference, the individual part 💖
4.7. The Aggregation Class PolicyActionInSARule 🎀
Level: MUST. Section 4.7 is the PolicyActionInSARule aggregation, the actions squad 👑
4.7.1. The Reference GroupComponent 🔥
Level: MUST. Section 4.7.1 is the GroupComponent reference for the actions 💅
4.7.2. The Reference PartComponent ✨
Level: MUST. Section 4.7.2 is the PartComponent reference for the actions 🌸
4.7.3. The Property ActionOrder 🫶
Level: SHOULD. Section 4.7.3 is the ActionOrder property, bestie keeps the order 💜
5. Condition and Filter Classes ✨
okay so this part is all about conditions and filters, and they are seriously iconic 💅 section 5 is where the matching happens 🦋
5.1. The Class SACondition 🌸
Level: MUST. Section 5.1 is the SACondition class, the condition that starts it all 💖
5.2 The Class IPHeadersFilter 🧚
Level: SHOULD. Section 5.2 is the IPHeadersFilter class, the IP header check 🌈
5.3. The Class CredentialFilterEntry 🍓
Level: MAY. Section 5.3 is the CredentialFilterEntry class, credentials, but make it cute 🎀
5.3.1. The Property MatchFieldName 💫
Level: MUST. Section 5.3.1 is the MatchFieldName property, the field name to match 🔥
5.3.2. The Property MatchFieldValue 🌸
Level: MUST. Section 5.3.2 is the MatchFieldValue property, the value to match 💅
5.3.3. The Property CredentialType 🦋
Level: MUST. Section 5.3.3 is the CredentialType property, the type of credential 🫶
5.4. The Class IPSOFilterEntry 💜
Level: MAY. Section 5.4 is the IPSOFilterEntry class, a filter entry with main character energy ✨
5.4.1. The Property MatchConditionType 🌈
Level: MUST. Section 5.4.1 is the MatchConditionType property, the kind of condition 💖
5.4.2. The Property MatchConditionValue 🍓
Level: MUST. Section 5.4.2 is the MatchConditionValue property, the value of the condition 👑
5.5. The Class PeerIDPayloadFilterEntry 🎀
Level: MAY. Section 5.5 is the PeerIDPayloadFilterEntry class, peer ID energy 🧚
5.5.1. The Property MatchIdentityType 🔥
Level: MUST. Section 5.5.1 is the MatchIdentityType property, the identity type 💅
5.5.2. The Property MatchIdentityValue 🌸
Level: MUST. Section 5.5.2 is the MatchIdentityValue property, the identity value 🫶
5.6. The Association Class FilterOfSACondition 💫
Level: SHOULD. Section 5.6 is the association class for the filter of an SACondition, bestie's link 🦋
5.6.1. The Reference Antecedent 💖
Level: MUST. Section 5.6.1 is the Reference Antecedent, the "from" side 🌈
5.6.2. The Reference Dependent 🍓
Level: MUST. Section 5.6.2 is the Reference Dependent, the "to" side 💜
5.7. The Association Class AcceptCredentialFrom 🎀
Level: MAY. Section 5.7 is the association class for accepting credentials from somewhere, the trust era 🔥
5.7.1. The Reference Antecedent ✨
Level: MUST. Section 5.7.1 is the Reference Antecedent, the source 🌸
5.7.2. The Reference Dependent 💅
Level: MUST. Section 5.7.2 is the Reference Dependent, the target 🫶
6. Action Classes 👑
okay bestie, actions are where things actually happen, and section 6 is a whole parade 🎉 let's see who's doing what 💖
6.1. The Class SAAction 🌈
Level: MUST. Section 6.1 is the SAAction class, the base action 💅
6.1.1. The Property DoActionLogging 🧚
Level: MAY. Section 6.1.1 is the DoActionLogging property, logging the action 📝
6.1.2. The Property DoPacketLogging 🌸
Level: MAY. Section 6.1.2 is the DoPacketLogging property, logging the packets 🦋
6.2. The Class SAStaticAction 🔥
Level: MUST. Section 6.2 is the SAStaticAction class, the static one 💜
6.2.1. The Property LifetimeSeconds 🍓
Level: MUST. Section 6.2.1 is the LifetimeSeconds property, measured in seconds ⏱️
6.3. The Class IPsecBypassAction 💫
Level: SHOULD. Section 6.3 is the IPsecBypassAction class, the bypass moment 🙈
6.4. The Class IPsecDiscardAction 🎀
Level: SHOULD. Section 6.4 is the IPsecDiscardAction class, the discard era 🗑️
6.5. The Class IKERejectAction 🫶
Level: MAY. Section 6.5 is the IKERejectAction class, the reject energy 💅
6.6. The Class PreconfiguredSAAction 💖
Level: MUST. Section 6.6 is the PreconfiguredSAAction class, pre-set and ready 👑
6.6.1. The Property LifetimeKilobytes 🌈
Level: MUST. Section 6.6.1 is the LifetimeKilobytes property, measured in kilobytes 🧃
6.7. The Class PreconfiguredTransportAction ✨
Level: MUST. Section 6.7 is the PreconfiguredTransportAction class, transport vibes 🚀
6.8. The Class PreconfiguredTunnelAction 🦋
Level: MUST. Section 6.8 is the PreconfiguredTunnelAction class, tunnel vibes 🌸
6.8.1. The Property DFHandling 🍓
Level: MUST. Section 6.8.1 is the DFHandling property, handle with care 🫶
6.9. The Class SANegotiationAction 💜
Level: MUST. Section 6.9 is the SANegotiationAction class, the negotiation glow-up 🤝
6.10. The Class IKENegotiationAction 🔥
Level: MUST. Section 6.10 is the IKENegotiationAction class, the IKE negotiation 💬
6.10.1. The Property MinLifetimeSeconds 🎀
Level: MAY. Section 6.10.1 is the MinLifetimeSeconds property, the minimum in seconds ⏱️
6.10.2. The Property MinLifetimeKilobytes 💅
Level: MAY. Section 6.10.2 is the MinLifetimeKilobytes property, the minimum in kilobytes 🧃
6.10.3. The Property IdleDurationSeconds 🌈
Level: MAY. Section 6.10.3 is the IdleDurationSeconds property, how long the idle lasts 😴
6.11. The Class IPsecAction 🧚
Level: MUST. Section 6.11 is the IPsecAction class, the IPsec action 💖
6.11.1. The Property UsePFS 🌸
Level: MUST. Section 6.11.1 is the UsePFS property, the PFS choice 🔐
6.11.2. The Property UseIKEGroup 🦋
Level: MAY. Section 6.11.2 is the UseIKEGroup property, the group choice 👥
6.11.3. The Property GroupId 💫
Level: MUST. Section 6.11.3 is the GroupId property, the group's ID 🪪
6.11.4. The Property Granularity 🍓
Level: SHOULD. Section 6.11.4 is the Granularity property, how fine-grained 🔍
6.11.5. The Property VendorID 🎀
Level: MAY. Section 6.11.5 is the VendorID property, the vendor's ID 🏷️
6.12. The Class IPsecTransportAction 💅
Level: MUST. Section 6.12 is the IPsecTransportAction class, transport mode energy 🚚
6.13. The Class IPsecTunnelAction 🌸
Level: MUST. Section 6.13 is the IPsecTunnelAction class, tunnel mode energy 🚇
6.13.1. The Property DFHandling 🔥
Level: MUST. Section 6.13.1 is the DFHandling property, once again, handle with care 🫶
6.14. The Class IKEAction 👑
Level: MUST. Section 6.14 is the IKEAction class, the IKE action 💬
6.14.1. The Property ExchangeMode 🦋
Level: MUST. Section 6.14.1 is the ExchangeMode property, the exchange style 🔄
6.14.2. The Property UseIKEIdentityType 🌈
Level: MUST. Section 6.14.2 is the UseIKEIdentityType property, the identity type choice 🪪
6.14.3. The Property VendorID 💖
Level: MAY. Section 6.14.3 is the VendorID property, vendor vibes 🏷️
6.14.4. The Property AggressiveModeGroupId 🍓
Level: MAY. Section 6.14.4 is the AggressiveModeGroupId property, the aggressive group 💪
6.15. The Class PeerGateway 💜
Level: MUST. Section 6.15 is the PeerGateway class, the peer's front door 🚪
6.15.1. The Property Name 🎀
Level: SHOULD. Section 6.15.1 is the Name property, the peer's name 🏷️
6.15.2. The Property PeerIdentityType 💅
Level: MUST. Section 6.15.2 is the PeerIdentityType property, the peer's identity type 🪪
6.15.3. The Property PeerIdentity 🌸
Level: MUST. Section 6.15.3 is the PeerIdentity property, the peer's identity 🫶
6.16. The Association Class PeerGatewayForTunnel 🧚
Level: MUST. Section 6.16 is the association class linking a peer gateway to a tunnel 🔗
6.16.1. The Reference Antecedent 🦋
Level: MUST. Section 6.16.1 is the Reference Antecedent, the "from" side 🌈
6.16.2. The Reference Dependent 💫
Level: MUST. Section 6.16.2 is the Reference Dependent, the "to" side 🍓
6.16.3. The Property SequenceNumber 🎀
Level: SHOULD. Section 6.16.3 is the SequenceNumber property, the order number 🔢
6.17. The Aggregation Class ContainedProposal 💖
Level: MUST. Section 6.17 is the ContainedProposal aggregation, a proposal group chat 💬
6.17.1. The Reference GroupComponent 💜
Level: MUST. Section 6.17.1 is the GroupComponent reference for the proposal 🌸
6.17.2. The Reference PartComponent 🔥
Level: MUST. Section 6.17.2 is the PartComponent reference for the proposal 🫶
6.17.3. The Property SequenceNumber ✨
Level: MUST. Section 6.17.3 is the SequenceNumber property, the proposal's order 🔢
6.18. The Association Class HostedPeerGatewayInformation 🌈
Level: MAY. Section 6.18 is the association class for the hosted peer gateway info 🏠
6.18.1. The Reference Antecedent 🍓
Level: MUST. Section 6.18.1 is the Reference Antecedent, the source 🌸
6.18.2. The Reference Dependent 💅
Level: MUST. Section 6.18.2 is the Reference Dependent, the target 🫶
6.19. The Association Class TransformOfPreconfiguredAction 🦋
Level: MUST. Section 6.19 is the association class for a transform of a preconfigured action 🔗
6.19.1. The Reference Antecedent 💫
Level: MUST. Section 6.19.1 is the Reference Antecedent, the "from" side 🌈
6.19.2. The Reference Dependent 🎀
Level: MUST. Section 6.19.2 is the Reference Dependent, the "to" side 💖
6.19.3. The Property SPI 🔢
Level: MUST. Section 6.19.3 is the SPI property, the security parameter index 🛡️
6.19.4. The Property Direction ➡️
Level: MUST. Section 6.19.4 is the Direction property, which way the traffic goes 🧭
6.20. The Association Class PeerGatewayForPreconfiguredTunnel 👑
Level: MUST. Section 6.20 is the association class linking a peer gateway to a preconfigured tunnel 🔗
6.20.1. The Reference Antecedent 🍓
Level: MUST. Section 6.20.1 is the Reference Antecedent, the source 🌸
6.20.2. The Reference Dependent 💜
Level: MUST. Section 6.20.2 is the Reference Dependent, the target 🫶
7. Proposal and Transform Classes 🌸
okay so proposals and transforms are the algorithm squad, and section 7 is giving nerd-core glam 🤓✨
7.1. The Abstract Class SAProposal 💖
Level: MUST. Section 7.1 is the abstract SAProposal class, the base proposal 💅
7.1.1. The Property Name 🎀
Level: SHOULD. Section 7.1.1 is the Name property, the proposal's name 🏷️
7.2 The Class IKEProposal 🦋
Level: MUST. Section 7.2 is the IKEProposal class, the IKE proposal 💬
7.2.1. The Property CipherAlgorithm 🔐
Level: MUST. Section 7.2.1 is the CipherAlgorithm property, the cipher choice 🔐
7.2.2. The Property HashAlgorithm 🌈
Level: MUST. Section 7.2.2 is the HashAlgorithm property, the hash choice #️⃣
7.2.3. The Property PRFAlgorithm 💫
Level: MAY. Section 7.2.3 is the PRFAlgorithm property, the PRF choice 🎲
7.2.4. The Property GroupId 🍓
Level: MUST. Section 7.2.4 is the GroupId property, the group's ID 🪪
7.2.5. The Property AuthenticationMethod 🎀
Level: MUST. Section 7.2.5 is the AuthenticationMethod property, how they prove it's them 🔑
7.2.6. The Property MaxLifetimeSeconds 🔥
Level: MUST. Section 7.2.6 is the MaxLifetimeSeconds property, the max in seconds ⏱️
7.2.7. The Property MaxLifetimeKilobytes ✨
Level: MUST. Section 7.2.7 is the MaxLifetimeKilobytes property, the max in kilobytes 🧃
7.2.8. The Property VendorID 🌸
Level: MAY. Section 7.2.8 is the VendorID property, vendor vibes 🏷️
7.3. The Class IPsecProposal 💅
Level: MUST. Section 7.3 is the IPsecProposal class, the IPsec proposal 🔐
7.4. The Abstract Class SATransform 🦋
Level: MUST. Section 7.4 is the abstract SATransform class, the base transform 🔄
7.4.1. The Property TransformName 🫶
Level: SHOULD. Section 7.4.1 is the TransformName property, the transform's name 🏷️
7.4.2. The Property VendorID 💖
Level: MAY. Section 7.4.2 is the VendorID property, vendor energy 🏷️
7.4.3. The Property MaxLifetimeSeconds 🌈
Level: MUST. Section 7.4.3 is the MaxLifetimeSeconds property, the max in seconds ⏱️
7.4.4. The Property MaxLifetimeKilobytes 🍓
Level: MUST. Section 7.4.4 is the MaxLifetimeKilobytes property, the max in kilobytes 🧃
7.5. The Class AHTransform 💜
Level: MUST. Section 7.5 is the AHTransform class, the AH transform 🛡️
7.5.1. The Property AHTransformId 🎀
Level: MUST. Section 7.5.1 is the AHTransformId property, the AH ID 🪪
7.5.2. The Property UseReplayPrevention 🔥
Level: MAY. Section 7.5.2 is the UseReplayPrevention property, the anti-replay choice 🔁
7.5.3. The Property ReplayPreventionWindowSize 💫
Level: MAY. Section 7.5.3 is the ReplayPreventionWindowSize property, the window size 🪟
7.6. The Class ESPTransform 🌸
Level: MUST. Section 7.6 is the ESPTransform class, the ESP transform 🔐
7.6.1. The Property IntegrityTransformId 🦋
Level: MUST. Section 7.6.1 is the IntegrityTransformId property, the integrity ID ✅
7.6.2. The Property CipherTransformId 💖
Level: MUST. Section 7.6.2 is the CipherTransformId property, the cipher ID 🔐
7.6.3. The Property CipherKeyLength 🍓
Level: MAY. Section 7.6.3 is the CipherKeyLength property, the key length 🗝️
7.6.4. The Property CipherKeyRounds 🌈
Level: MAY. Section 7.6.4 is the CipherKeyRounds property, the rounds 🔁
7.6.5. The Property UseReplayPrevention 💅
Level: MAY. Section 7.6.5 is the UseReplayPrevention property, anti-replay again 🔁
7.6.6. The Property ReplayPreventionWindowSize 🫶
Level: MAY. Section 7.6.6 is the ReplayPreventionWindowSize property, the window again 🪟
7.7. The Class IPCOMPTransform 💜
Level: MAY. Section 7.7 is the IPCOMPTransform class, the compression transform 🗜️
7.7.1. The Property Algorithm 🎀
Level: MUST. Section 7.7.1 is the Algorithm property, the algorithm choice 🧮
7.7.2. The Property DictionarySize 🔥
Level: MAY. Section 7.7.2 is the DictionarySize property, the dictionary size 📚
7.7.3. The Property PrivateAlgorithm ✨
Level: MAY. Section 7.7.3 is the PrivateAlgorithm property, the private algorithm 🤫
7.8. The Association Class SAProposalInSystem 🌸
Level: MAY. Section 7.8 is the association class for an SA proposal in a system 🔗
7.8.1. The Reference Antecedent 🦋
Level: MUST. Section 7.8.1 is the Reference Antecedent, the "from" side 🌈
7.8.2. The Reference Dependent 💖
Level: MUST. Section 7.8.2 is the Reference Dependent, the "to" side 🍓
7.9. The Aggregation Class ContainedTransform 🍓
Level: MUST. Section 7.9 is the ContainedTransform aggregation, the transform group chat 💬
7.9.1. The Reference GroupComponent 💜
Level: MUST. Section 7.9.1 is the GroupComponent reference for the transform 🌸
7.9.2. The Reference PartComponent 🎀
Level: MUST. Section 7.9.2 is the PartComponent reference for the transform 🫶
7.9.3. The Property SequenceNumber 🔥
Level: MUST. Section 7.9.3 is the SequenceNumber property, the transform's order 🔢
7.10. The Association Class SATransformInSystem 💫
Level: MAY. Section 7.10 is the association class for an SA transform in a system 🔗
7.10.1. The Reference Antecedent 🌈
Level: MUST. Section 7.10.1 is the Reference Antecedent, the source 🌸
7.10.2. The Reference Dependent 💅
Level: MUST. Section 7.10.2 is the Reference Dependent, the target 🫶
8. IKE Service and Identity Classes 🫶
okay bestie, the IKE service and identity classes are the final boss of this section, and they are absolutely iconic 👑💖
8.1. The Class IKEService 🦋
Level: MAY. Section 8.1 is the IKEService class, the service itself 🛎️
8.2. The Class PeerIdentityTable 🌈
Level: MAY. Section 8.2 is the PeerIdentityTable class, the table of peers 📋
8.3.1. The Property Name 🎀
Level: SHOULD. Section 8.3.1 is the Name property, the table entry's name 🏷️
8.3. The Class PeerIdentityEntry 💜
Level: MAY. Section 8.3 is the PeerIdentityEntry class, one peer's entry 🧾
8.3.1. The Property PeerIdentity 🔥
Level: SHOULD. Section 8.3.1 is the PeerIdentity property, the peer's identity 🪪
8.3.2. The Property PeerIdentityType 🍓
Level: SHOULD. Section 8.3.2 is the PeerIdentityType property, the identity type 🪪
8.3.3. The Property PeerAddress 💫
Level: SHOULD. Section 8.3.3 is the PeerAddress property, where the peer lives 📍
8.3.4. The Property PeerAddressType 🌸
Level: SHOULD. Section 8.3.4 is the PeerAddressType property, the address type 🏠
8.4. The Class AutostartIKEConfiguration 💅
Level: MAY. Section 8.4 is the AutostartIKEConfiguration class, the autostart setup 🚀
8.5. The Class AutostartIKESetting 🫶
Level: MAY. Section 8.5 is the AutostartIKESetting class, the autostart settings ⚙️
8.5.1. The Property Phase1Only 💖
Level: MAY. Section 8.5.1 is the Phase1Only property, phase one only 1️⃣
8.5.2. The Property AddressType 🌈
Level: SHOULD. Section 8.5.2 is the AddressType property, the address type 🏠
8.5.3. The Property SourceAddress 🍓
Level: MUST. Section 8.5.3 is the SourceAddress property, where it comes from 📤
8.5.4. The Property SourcePort 🎀
Level: MUST. Section 8.5.4 is the SourcePort property, the source port 🚪
8.5.5. The Property DestinationAddress 🔥
Level: MUST. Section 8.5.5 is the DestinationAddress property, where it's going 📥
8.5.6. The Property DestinationPort ✨
Level: MUST. Section 8.5.6 is the DestinationPort property, the destination port 🚪
8.5.7. The Property Protocol 🌸
Level: MUST. Section 8.5.7 is the Protocol property, the protocol choice 📡
8.6. The Class IKEIdentity 🦋
Level: MAY. Section 8.6 is the IKEIdentity class, the IKE identity 🪪
8.6.1. The Property IdentityType 💫
Level: MUST. Section 8.6.1 is the IdentityType property, the identity type 🪪
8.6.2. The Property IdentityValue 💖
Level: MUST. Section 8.6.2 is the IdentityValue property, the identity value 🧾
8.6.3. The Property IdentityContexts 🌈
Level: MAY. Section 8.6.3 is the IdentityContexts property, the contexts again 🌍
8.7.1. The Reference Antecedent................................MUST
8.7.2. The Reference Dependent.................................MUST
8.8. The Aggregation Class PeerIdentityMember...................MAY
8.8.1. The Reference Collection................................MUST
8.8.2. The Reference Member....................................MUST
8.9. The Association Class IKEServicePeerGateway................MAY
8.9.1. The Reference Antecedent................................MUST
8.9.2. The Reference Dependent.................................MUST
8.10. The Association Class IKEServicePeerIdentityTable.........MAY
8.10.1. The Reference Antecedent...............................MUST
8.10.2. The Reference Dependent................................MUST
8.11. The Association Class IKEAutostartSetting.................MAY
8.11.1. The Reference Element..................................MUST
8.11.2. The Reference Setting..................................MUST
8.12. The Aggregation Class AutostartIKESettingContext..........MAY
8.12.1. The Reference Context..................................MUST
8.12.2. The Reference Setting..................................MUST
8.12.3. The Property SequenceNumber..........................SHOULD
8.13. The Association Class IKEServiceForEndpoint...............MAY
8.13.1. The Reference Antecedent...............................MUST
8.13.2. The Reference Dependent................................MUST
8.14. The Association Class IKEAutostartConfiguration...........MAY
8.14.1. The Reference Antecedent...............................MUST
8.14.2. The Reference Dependent................................MUST
8.14.3. The Property Active..................................SHOULD
8.15. The Association Class IKEUsesCredentialManagementService..MAY
8.15.1. The Reference Antecedent...............................MUST
8.15.2. The Reference Dependent................................MUST
8.16. The Association Class EndpointHasLocalIKEIdentity.........MAY
8.16.1. The Reference Antecedent...............................MUST
8.16.2. The Reference Dependent................................MUST
8.17. The Association Class CollectionHasLocalIKEIdentity.......MAY
8.17.1. The Reference Antecedent...............................MUST
8.17.2. The Reference Dependent................................MUST
8.18. The Association Class IKEIdentitysCredential..............MAY
8.18.1. The Reference Antecedent...............................MUST
8.18.2. The Reference Dependent................................MUST10. Security Considerations 🔐
Okay bestie, this section is dead serious 💀🔐. This document only describes an information model for IPsec policy. It does not detail security requirements for storage or delivery of said information.
Physical models derived from this information model MUST implement the relevant security for storage and delivery. Most of the classes (e.g., IpHeadersFilter, SAAction,...) MUST at least provided the integrity service. Other pieces of information MUST also receive the confidentiality service (e.g., SharedSecret as described in the classes PeerIdentityEntry and PreconfiguredSAAction). 🫶
11. Intellectual Property Statement 📜
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also does not represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 💌
12. References 📚
12.1. Normative References
[COMP]Shacham, A., Monsour, B., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.[ESP]Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.[AH]Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.[DOI]Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.[IKE]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.[PCIM]Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.[PCIME]Moore, B., Editor, "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[CIMCORE]DMTF Common Information Model - Core Model v2.5 which can be found athttp://www.dmtf.org/standards/CIM_Schema25/CIM_Core25.mof[CIMUSER]DMTF Common Information Model - User-Security Model v2.5 which can be found athttp://www.dmtf.org/standards/CIM_Schema25/CIM_User25.mof[CIMNETWORK]DMTF Common Information Model - Network Model v2.5 which can be found athttp://www.dmtf.org/standards/CIM_Schema25/CIM_Network25.mof[IPSO]Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.[IPSEC]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
12.2. Informative References
[LDAP]Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.[COPS]Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.[COPSPR]Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, R., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.[DMTF]Distributed Management Task Force,http://www.dmtf.org/
13. Disclaimer 🙅♀️
The views and specification herein are those of the authors and are not necessarily those of their employer. The authors and their employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
14. Acknowledgments 🌸
The authors would like to thank Mike Jeronimo, Ylian Saint-Hilaire, Vic Lortz, William Dixon, Man Li, Wes Hardaker and Ricky Charlet for their contributions to this IPsec policy model. 🫶
Additionally, this document would not have been possible without the preceding IPsec schema documents. For that, thanks go out to Rob Adams, Partha Bhattacharya, William Dixon, Roy Pereira, and Raju Rajan. 💖
15. Authors' Addresses 🦋
Jamie Jason
Intel Corporation
MS JF3-206
2111 NE 25th Ave.
Hillsboro, OR 97124
EMail: jamie.jason@intel.com
Lee Rafalow
IBM Corporation, BRQA/502
4205 So. Miami Blvd.
Research Triangle Park, NC 27709
EMail: rafalow@watson.ibm.com
Eric Vyncke
Cisco Systems
7 De Kleetlaan
B-1831 Diegem
Belgium
EMail: evyncke@cisco.com16. Full Copyright Statement ©️
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3585 2003-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms