Subject: [I2nsf] Post 5: Specific worries about the "Subject-Object-Action-Function"

From: John Strassner <[email-masked]>
Date: Thu, 18 Feb 2016 17:40:13 -0800

Post 5:  Specific worries about the "Subject-Object-Action-Function"
         Paradigm in the Framework draft

I expressed discomfort with the "Subject-Object-Action-Function" (SOAF)
paradigm used in the Framework draft at IETF94. This note explains
these worries in more detail.

1.  Background - Framework Terminology

   None of the SOAF terms are formally defined; rather, they are
   explained informally, as follows:

     - Subject-Match values, based on packet data, packet header, or
       packet payload, which can be one or more header fields or bits
       in the packets, or the various combination of them;
     - Object-Match values, based on context (e.g., state, direction of
       the traffic, time, geo-location, etc.);
     - Action-Egress processing, such as invoke signaling, packet
       forwarding and/or transformation, SDN/NFV integration;
     - Functional Profile - a functional profile is a specific
       organization of characteristics and/or behavior of that define
       the functionality offered by an entity (e.g., IPS:<Profile>,
       signature file, Anti-virus file, URL filtering file, etc.).
       Integrated and one-pass checks on the content of packets are
       examples of a functional profile.

   Section 6.1 also provides the following guidelines:

   The "subject" of the I2NSF policies should not only include the
   matching criteria specified by [ACL-MODEL] but also the L4-L7
   fields depending on the NSFs selected.

   The I2NSF Capability Layer has to specify the "Object" (i.e. the
   context surrounding the packets).

   The I2NSF "actions" should extend the actions specified by [ACL-
   MODEL] to include applying statistics functions that clients
   provide.

2.  Comparison Basis

   Between the start of my posts and now, the I2NSF WG has started
   considering the paradigm of policy rules (specifically, event-
   condition-action policy rules). These may be abstracted as about
   particular type of sentence. The SOAF terms will be compared to
   sentences below.

3.  Worries about using the term "Subject"

   The "subject" term in SOAF is exclusively limited to "packet data,
   packet header, or packet payload" information. This presents
   several problems, including:

     o  From linguistics, the **subject** of a sentence is a person,
        place, thing, or concept that is doing or being something.
        Packet information is not a subject by this definition;
        rather, packet information should be part of the predicate of
        a sentence.
     o  The term "subject" has traditionally been used in policy
        management systems to refer to users or other entities that
        have management responsibility. The concept of a subject is
        critical for authorization policies.
     o  Packet information is typically used as part of a condition,
        though it could also be the target of a policy, meaning
        that some of the packet's data may be changed by the action(s)
        of a policy. Hence, it is not appropriate as defined.

   A related worry is the very narrow definition of subject in section
   1. However, since subject and object from SOAF will be combined (see
   section 3), this is not logged as a problem.

4.  Worries about using the term "Object"

   The "object" term in SOAF suffers from being too generic (e.g.,
   anything could be an object). This presents several problems,
   including:

     o  From linguistics, there are **two** types of objects:
        - a direct object is the receiver of an action in a sentence
        - an indirect object identifies to (or for) whom the action
          is performed
        It is therefore unclear which object is referred to in SOAF.
     o  The definition of "object-match" values is based on context,
        but unfortunately, context is not defined. Please see
        http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html
        for a defintiion of context.
     o  The phrase "object-match" [sic] means that the "object" (or
        presumably, one or more of its attributes), are being tested
        against another object. This means that it, like "subject", is
        also playing the role of a condition, which is odd.

5.  Worries about using the term "Action"

   The "action" term in SOAF is not defined. The examples given imply
   that it is similar in nature to a standard policy action, though
   with a more reduced scope of actions that can be defined. However,
   figure 3 is confusing. There is a connection between "action" and
   "Simple Actions", as well as between "action" and "function
   Profile". The connection is neither labeled nor annotated, so it is
   unclear what is meant. However, the worry is that somehow, about
   "Function Profile" is a type of action; this will be addressed in
   the following section.

6.  Worries about using the term "Function"

   The "function" term in SOAF very confusing. The term "function" is
   combined with "profile"; the problem with this is that "functions"
   and "profiles" are very different types of entities. In addition,
   the examples of "profiles" given do not match the traditional
   definition of a "profile", such as that of a user of device profile;
   see UAProf or CC/PP for examples.

   If the purpose of this term is really to "define the functionality
   offered by an entity", then it does not belong with actions at all
   (as is implied in Figure 3); rather, it appears to be part of the
   condition. For example, comparing a signature file would seem to be
   part of the condition of a rule, not an action.

7.  Conclusions

   The "subject", "object", and "function" terms in SOAF are confusing
   and likely misnamed. It is unclear what value SOAF offers over the
   concept of a traditional policy rule. Hence, this will be the
   subject of my last (hopefully) post.

   Note: the text in 6.2 "However, the notion of Groups (or roles),
   Target, Context (or conditions), and Action do cover what is needed
   for clients/applications to express the rules on how their flows can
   be treated by the Flow-Based NSFs in networks" needs to change.

   Note 2:  the framework draft recommended using PCIM as a basis for
   policy rules. Please see Posts 2a and 2b for why this is a BAD idea.
   References for those posts are:
   http://www.ietf.org/mail-archive/web/i2nsf/current/msg00736.html and
   http://www.ietf.org/mail-archive/web/i2nsf/current/msg00737.html

   Alternatively, see Appendix A in
   draft-strassner-supa-generic-policy-info-model-04, which goes into
   additional detail why PCIM and PCIMe were NOT used as a basis for
   However, the notion of Groups (or roles), Target, Context (or

regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 25 Feb 2016 20:19:10 +0000

John,

Thank you very much for the comprehensive write-up. That is very good.

With more support & trend going to ECA model, can you provide a suggestion on the “terminology” that  is the matching criteria (i.e. condition) based on N-tuples in  packets? V.s. the matching criteria based on others (such as internal variables, states, ports, or others)?

As for the “action” of the  “Functional profile”, the intent was to describe the “Action of applying a specific profile or signature file to the packets” ( as compared to the “action” of passing, dropping or rate limiting the packets).

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, February 18, 2016 7:40 PM
To: [email-masked]
Subject: [I2nsf] Post 5: Specific worries about the "Subject-Object-Action-Function"

2.  Comparison Basis

7.  Conclusions

regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 28 Feb 2016 17:00:47 -0800

Hi Linda,

thank you for your kind words. I will try and devote Monday to providing a
detailed round of editing to the terminology draft, so that we can get this
out to the WG soon. In this edit, I will expand on what you are saying
(without giving an academic treatise :-)  ).

Thank you for emphasizing the intent of the "functional profile" - I will
give it some serious thought and include it in my edits to the terminology
draft co-authors. Clearly, we need this term defined (note that Sue already
defined the term "profile" and my concerns about it).

regards,
John

On Thu, Feb 25, 2016 at 12:19 PM, Linda Dunbar <[email-masked]>
wrote:

> With more support & trend going to ECA model, can you provide a suggestion
> on the “terminology” that  is the matching criteria (i.e. condition) based
> on N-tuples in  packets? V.s. the matching criteria based on others (such
> as internal variables, states, ports, or others)?
>
>
>
>
>
> As for the “action” of the  “Functional profile”, the intent was to
> describe the “Action of applying a specific profile or signature file to
> the packets” ( as compared to the “action” of passing, dropping or rate
> limiting the packets).
>
>
>
> Linda
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, February 18, 2016 7:40 PM
> *To:* [email-masked]
> *Subject:* [I2nsf] Post 5: Specific worries about the
> "Subject-Object-Action-Function"
>
>
>

-- 
regards,
John