[I2nsf] Post 2a: Background Information on PCIMe (Overview)
John Strassner <strazpdj@gmail.com> Fri, 11 December 2015 21:55 UTC
Return-Path: <strazpdj@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F3C1A1B2D for <i2nsf@ietfa.amsl.com>; Fri, 11 Dec 2015 13:55:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTQo9y-LUdfF for <i2nsf@ietfa.amsl.com>; Fri, 11 Dec 2015 13:55:15 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2DF1A00F5 for <i2nsf@ietf.org>; Fri, 11 Dec 2015 13:55:14 -0800 (PST)
Received: by vkca188 with SMTP id a188so124773488vkc.0 for <i2nsf@ietf.org>; Fri, 11 Dec 2015 13:55:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RE0jKkOamC1SY5c02jwGRxeVPzw65rX8BO+1HOvlR6s=; b=fJMUX1L6oK212lQHIVRKHguYScs07AvxzAL3YHwhlt24UH21h6UL2mdzo0+8ruRmWr 7Z8TX22PBRAqoufWDCTJv+QcaHVma/qpt3L4JmVc6ZshkErei2xL9TIMQfU7Zs0hbso0 oyTqrs1uqnTJiTGaKhmZFs7vpJHaKR1uQO4XosWuM2ppicG/Cg3bmdllJSL7Bu4jlKZD 6xibxgD2YURIvrhQ0CA6gr4Okbc49NKh4Y7SRyYaK9Fr/gmJGt42gdp+DKVPiadE5qYm 7ZlWm9NKOAokVDfKMJui6QnyTKdKEbmxmk+fW66Xnf6geyTdwBx7bOTwJMz3WO6FFiu+ 5LlA==
MIME-Version: 1.0
X-Received: by 10.31.60.4 with SMTP id j4mr15789492vka.109.1449870913922; Fri, 11 Dec 2015 13:55:13 -0800 (PST)
Received: by 10.103.40.131 with HTTP; Fri, 11 Dec 2015 13:55:13 -0800 (PST)
Date: Fri, 11 Dec 2015 13:55:13 -0800
Message-ID: <CAJwYUrHijp_uKZeA4h7SSfar6aVHfAWc2oFhBY8bMWh7xFg2mw@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: i2nsf@ietf.org
Content-Type: multipart/alternative; boundary="001a11c00f90cb6d4d0526a660c6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/0IKMzBDEMQcTpaaKnLzRkRRko_0>
Subject: [I2nsf] Post 2a: Background Information on PCIMe (Overview)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2015 21:55:19 -0000
The I2NSF framework draft mentions PCIM (RFC3060) and PCIMe (RFC3460) as possible candidates for guiding the policy structure that can be mapped to the Capability Layer's "Subject-Object-Action-Function" paradigm. This note provides a brief analysis of the suitability of PCIMe for this task. Attributes in PCIM and PCIMe do not obey standard coding conventions of nonCapThenCap, they are CapThenCap. Please note that I name attributes in the traditional nonCapThenCap manner in the following discussion. Finally, sorry for the length of this note, but RFC3460 is a 93-page document, and even more complex than PCIM. Therefore, I have tried to keep this as brief as possible by splitting it into two, called Post 2a and Post 2b. This post (2a) gives a high-level overview, and is intended for non-modelers. Post 2b adds detail to post 2a, and is intended for modelers. If you need more explanation on anything, please do not hesitate to ask! 1. Focus of PCIMe PCIMe was built to accomplish two things: 1) EXTEND PCIM into areas that were being worked on at the time (e.g., header filtering), and 2) DEPRECATE parts of PCIM based on early experience 1.1. EXTENSION In general, extensions should not cause a problem, but there are exceptions - the most important is PolicySet (parent of PolicyGroup and PolicyRule). Please read Post 2b, section 1.1, for more detail on this. 1.2. DEPRECATION Deprecation is sometimes unavoidable. In general, such changes are not backwards-compatible. Note that PCIMe does not include in its class definitions annotations as to why a particular element was deprecated. 2. SUMMARY: main drawbacks of using PCIMe Note that the current CIM Policy Model (2.44.1) is significantly different than either PCIM or PCIMe. PCIM is based on CIM 2.4; PCIMe is based on CIM 2.5. PCIMe is NOT backwards compatible with PCIM in all areas. Note also that many of the deprecated items in 2.4 and 2.5 still exist in 2.44.1, though some have been removed. Given the large amount of problems, I recommend that we do not consider PCIMe further for I2NSF work. 2.1. Critical Problems These are in addition to those pointed out in Post 1. 2.1.1. Policy Rule Problems - There is no way to properly aggregate PolicyRules into PolicyGroups. PolicySetComponent is recursive, so it can be used to aggregate homogeneous, but not heterogeneous, objects - Nested policy rules (also called sub-rules) are no different than making a method call to another PolicyAction; this would greatly simplify implementation and understanding (see Post 2b) - There is no mechanism to make use of the executionStrategy attribute, since neither errors nor events are defined - There is no mechanism that can prevent side effects caused by the evaluation of conditions - There is no mechanism that can prevent side effects caused by the execution of actions 2.1.2. Role Problems - Using attributes (i.e., policyRoles) to associate a PolicyRule to a resource is broken. This is what associations, aggregations, and compositions are for - Worse, the mechanism for aggregating roles is **backwards** in PCIMe. Roles describe object responsibilities, and there should be the object that is aggregated by an entity (see Post 2b) - Worse yet, there is no mechanism for ensuring that the resource object and the PolicyRoleCollection objects are scoped by the same System - Finally, there is no mechanism for role inheritance and role engineering to be performed (see Post 2b) 2.1.3. Conditions and Actions - There is no reason to define the SimplePolicyCondition and CompoundPolicyCondition classes - There is no reason to define the SimplePolicyAction and CompoundPolicyAction classes 2.1.4. Variables - There is no reason to have both a PolicyImplicitVariable and a PolicyExplicitVariable class (see Post 2b); they are performing the same semantic function 2.1.5. Additional Problems These are so important that they are repeated from Post 1: - There is no way to uniquely identify instances of the same object - There is no concept of error or exception handling - There is no concept of the subject or the target of a policy - Adding a new type of policy (e.g., declarative or functional) will cause a major rewrite of the entire model - There is no approach to detecting and solving policy conflicts 2.2. Major Problems 2.2.1. Abstraction Problems - The "levels of abstraction" (domain- and device-level policies) have no mechanisms defined in the model to support them - The PolicyComponent aggregation, defined on Policy, means that ANY SUBCLASS can aggregate itself, which is incorrect. - Scoping has no mechanisms to ensure that the PolicyRule and the resource to which it applies are in the same namespace. - First, weak relationships (a relational algebra construct), should not be used in information models. - Second, this requires two relationships (one for PolicyGroup and a different one for PolicyRule) to be used. - Third, the PCIMe implementation uses overriding of keys (!) to implement these aggregations. 2.2.2. PolicyRule Problems - The "first-match" decision strategy can be ambiguous (see Post 2b) - The decisionStrategy attribute can be ambiguous (see Post 2b) - There is no mechanism to ensure that priority attribute values are unique within a PolicySet (or PolicySetInSystem); this leads to non-deterministic behavior - Different classes are required to associate each condition with a PolicyRule - Different classes are required to associate each action with a PolicyRule 2.2.3. Condition and Action Problems - The MATCH operator is overloaded and ambiguous (see Post 2b) - CompoundPolicyConditions are very expensive (see Post 2b) - This also applies to CompoundPolicyActions - Building a Boolean condition clause is complex and requires too many aggregations (see Post 2b) - The above is more complex when PolicyConditions are nested, as well as when CompoundPolicyConditions are used (see Post 2b) - The above two points apply equally to PolicyActions 2.2.4. Miscellaneous Problems - The associations PolicyInSystem, PolicyGroupInSystem, and PolicyRuleInSystem are superfluous (see Post 2b) - Filters are too difficult to construct (see Post 2b) 2.3. Minor Problems - PolicyRule has an attribute named "mandatory" whose semantics are ambiguous depending on the values of other attributes - The class CompoundFilterCondition defines one additional attribute; this is insufficient to standardize how filtering conditions should be structured - Copying the attributes sequencedActions and executionStrategy in both PolicyRule and CompoundPolicyAction does not make sense - All ImplicitPolicyVariable subclasses have no mechanism to enforce their allowed value types (see Post 2b) - The ReusablePolicyContainer class does not define any useful attributes for policy-based management 3. PCIMe Class Hierarchy The PCIMe Class Hierarchy is still a CA (condition-action) model, as shown below (changes are briefly noted in parentheses): ManagedElement (abstract) | +---Policy (abstract) | | | +---PolicySet (abstract, new) | | | | | +---PolicyGroup (MOVED to here) | | | | | +---PolicyRule (MOVED to here) | | | +---PolicyCondition (abstract) | | | | | +---PolicyTimePeriodCondition | | | | | +---VendorPolicyCondition | | | | | +---SimplePolicyCondition (NEW) | | | | | +---CompoundPolicyCondition (NEW) | | | | | +---PolicyFilterCondition (NEW) | | | +---PolicyAction (abstract) | | | | | +---VendorPolicyAction | | | | | +---SimplePolicyAction (NEW) | | | | | +---CompoundPolicyAction (NEW) | | | | +---PolicyVariable (abstract, NEW) | | | | | +---PolicyExplicitVariable (NEW) | | | | | +---PolicyImplicitVariable (abstract, NEW) | | | | | +---(NEW SUBCLASSES) | | | +---PolicyValue (abstract, NEW) | | | | | +---(NEW SUBCLASSES) | | | +---Collection (Abstract, NEW*) | | | | | +---PolicyRoleCollection (NEW) | | | +---ManagedSystemElement (abstract, NEW*) | | | | | +---LogicalElement (abstract, NEW*) | | | | | | | +---System (abstract, NEW*) | | | | | | | | | ... (deprecated PolicyRepository with ReusablePolicyContainer, NEW*) | | | | | | | +---FilterEntryBase (abstract, NEW*) | | | | | | | | | +---IpHeadersFilter (NEW)* | | | | | | | | | +---8021Filter (NEW*) | | | | | | | | +---FilterList (NEW*) Note that RFC3460 says that the classes marked by NEW* are not new, as they are defined in the CIM. However, they ARE new to PCIMe, so I have marked them as NEW*. See additional notes in Post 2b if desired. regards, John
- [I2nsf] Post 2a: Background Information on PCIMe … John Strassner