Subject: [I2nsf] Service Layer Policies - Post 0: note structure

From: John Strassner <[email-masked]>
Date: Sun, 6 Dec 2015 17:00:21 -0800

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.
During IETF94, I expressed discomfort with the above paradigm. However,
this is a complex subject, and is more easily understood by breaking this
up into smaller discussions. Here is the order of notes that I will post:

   Post 0:  this post
   Post 1:  problems in using PCIM
   Post 2:  problems in using PCIMe
   Post 3:  differentiating between groups and roles
   Post 4:  differentiating between context, constraints, and conditions
   Post 5:  specific worries about the "Subject-Object-Action-Function"
paradigm
   Post 6:  proposed replacement policy structure

Posts 1 and 2 clarify the problems in using PCIM and PCIMe, respectively,
which I volunteered to do.

Posts 3 and 4 are fundamental to posts 5 and 6, as they represent software
building blocks that are critical for designing and implementing Service
Policies in a scalable and robust manner. These also expand on points in
posts 1 and 2.

Post 5 is the heart of the manner, but can't really be tackled until the
preceding posts were done. Post 6 builds on the previous posts.

regards,
John
-- 
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 7 Dec 2015 21:25:44 +0000

John,

Thank you very much for structuring the discussion. This is very helpful.

Maybe I am jumping ahead. For Post 5,  the “object” currently used in I2NSF framework is same as the  “Condition” in PCIM to describe the constraints. If no one disagree, I propose to align with PCIM, i.e. call it “Subject-Condition-Action-Function”.

Regards,
Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, December 06, 2015 7:00 PM
To: [email-masked]
Subject: [I2nsf] Service Layer Policies - Post 0: note structure

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.
During IETF94, I expressed discomfort with the above paradigm. However, this is a complex subject, and is more easily understood by breaking this up into smaller discussions. Here is the order of notes that I will post:

   Post 0:  this post
   Post 5:  specific worries about the "Subject-Object-Action-Function" paradigm

Posts 1 and 2 clarify the problems in using PCIM and PCIMe, respectively, which I volunteered to do.

Posts 3 and 4 are fundamental to posts 5 and 6, as they represent software building blocks that are critical for designing and implementing Service Policies in a scalable and robust manner. These also expand on points in posts 1 and 2.

Post 5 is the heart of the manner, but can't really be tackled until the preceding posts were done. Post 6 builds on the previous posts.

regards,
John
--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 7 Dec 2015 13:33:57 -0800

Hi Linda,

you are jumping ahead :-)

First, read post 1. Aligning to PCIM is a BAD idea. Note that PCIMe will
have
a **different** set of problems, but jumping ahead, that is not advised
either.

Second, here are two fundamental problems with
subject-object-action-function:

   1) subject is currently also a condition :-(
   2) the current definition of subject prohibits deontic logic in general
        and authorization policies in particular

More later.

best regards,
John

On Mon, Dec 7, 2015 at 1:25 PM, Linda Dunbar <[email-masked]>
wrote:

> Maybe I am jumping ahead. For Post 5,  the “object” currently used in
> I2NSF framework is same as the  “Condition” in PCIM to describe the
> constraints. If no one disagree, I propose to align with PCIM, i.e. call it
> “Subject-Condition-Action-Function”.
>
>
>
> Regards,
>
> Linda
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, December 06, 2015 7:00 PM
> *To:* [email-masked]
> *Subject:* [I2nsf] Service Layer Policies - Post 0: note structure
>
>
>

-- 
regards,
John

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 8 Dec 2015 09:37:59 +0000

Hi,

I support this. I think it is good to be aligned with common usage of terms, unless there are very good reasons to do otherwise.

Just for the record, we are collecting some of the (already mature) results of the SECURED project policy efforts into a document we will contribute anytime soon. I hope we will be well aligned with John’s ideas.

Be goode,

On 7 Dec 2015, at 22:25 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

John,

Regards,
Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, December 06, 2015 7:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Service Layer Policies - Post 0: note structure

   Post 0:  this post

regards,
John
--
regards,
John
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Aldo Basile <[email-masked]>
Date: Wed, 9 Dec 2015 12:43:08 +0100

Dear all,

I agree it is not worth considering the whole PCIM or PCIMe models and 
suggested implementations. They are too complex to implement and 
maintain and far from being perfect (John Strassner's Posts 0/1 are much 
more precise references to PCIM issues).

However, I think PCIM/PCIMe are excellent starting points for the design 
of the an information model, thus they can be used for I2NSF as well.

In my experience, all the policy-related concepts that one may need 
during such a design phase can be described by referring to 
PCIM/PCIMe-defined concepts (regardless of the way they are represented, 
classes, associations, association classes), concepts that PCIM/PCIMe 
miss, and concepts that are not correctly/optimally represented in 
PCIM/PCIMe.

In the SECURED project (and before in the PoSecCo project), PCIM/PCIMe 
have been considered as starting point to design the information and 
data models (which are now similar but not equal), while the actual 
implementation of the repositories and management tasks have been 
completely detached from PCIM/PCIMe (we had indeed a bad experience in 
fully agreeing with PCIM during a previous POSITIF project).

Therefore, it is probably worth considering the 'refinement' of the 
I2NSF requirements (which, to the best of my knowledge are presented 
here https://datatracker.ietf.org/wg/i2nsf/charter/, please correct me 
if I'm wrong) to a set of more formal/precisely defined requirements and 
probably also inputs from use cases.

Only at that point it would be possible to precisely understand what we 
can reuse from existing (de facto) standards or models.

Regards,
Cataldo

On 08/12/2015 10:37, DIEGO LOPEZ GARCIA wrote:
> Hi,
>
> I support this. I think it is good to be aligned with common usage of
> terms, unless there are very good reasons to do otherwise.
>
> Just for the record, we are collecting some of the (already mature)
> results of the SECURED project policy efforts into a document we will
> contribute anytime soon. I hope we will be well aligned with John’s ideas.
>
> Be goode,
>
>> constraints. If no one disagree, I propose to align with PCIM, i.e.
>> call it “Subject-Condition-Action-Function”.
>> Regards,
>> Linda
>> *From:*I2nsf [mailto:[email-masked]]*On Behalf Of*John Strassner
>> *Sent:*Sunday, December 06, 2015 7:00 PM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[I2nsf] Service Layer Policies - Post 0: note structure
>> 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.
>> During IETF94, I expressed discomfort with the above paradigm.
>> However, this is a complex subject, and is more easily understood by
>> breaking this up into smaller discussions. Here is the order of notes
>> that I will post:
>>    Post 0:  this post
>>    Post 5:  specific worries about the
>> "Subject-Object-Action-Function" paradigm
>> Posts 3 and 4 are fundamental to posts 5 and 6, as they represent
>> software building blocks that are critical for designing and
>> implementing Service Policies in a scalable and robust manner. These
>> also expand on points in posts 1 and 2.
>> Post 5 is the heart of the manner, but can't really be tackled until
>> the preceding posts were done. Post 6 builds on the previous posts.
>> regards,
>> John
>> --
>> regards,
>> John
>> [email-masked] <mailto:[email-masked]>
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud
> de la legislación vigente. Si ha recibido este mensaje por error, le
> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda
> a su destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited. If you have
> received this transmission in error, do not read it. Please immediately
> reply to the sender that you have received this communication in error
> and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida em
> virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição
>
>
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 9 Dec 2015 23:54:43 +0000

Aldo, 

Thank you for the suggestion. 

Just want to add a note: I2NSF only deals with rule-set/policy for treating packets/flows traversing through NSF. Therefore, the I2NSF polices would be much simpler, which doesn't need to deal with network wide policies or user policies. 

Linda

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]] 
Sent: Wednesday, December 09, 2015 5:43 AM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]; John Strassner
Subject: Re: [I2nsf] Service Layer Policies - Post 0: note structure

Dear all,

Regards,
Cataldo

On 08/12/2015 10:37, DIEGO LOPEZ GARCIA wrote:
> contribute anytime soon. I hope we will be well aligned with John's ideas.
>
> Be goode,
>
>> Maybe I am jumping ahead. For Post 5,  the "object" currently used in
>> I2NSF framework is same as the  "Condition" in PCIM to describe the
>> call it "Subject-Condition-Action-Function".
>> Regards,
>> Linda

---

From: John Strassner <[email-masked]>
Date: Thu, 10 Dec 2015 11:15:21 -0800

Hi all,
Aldo wrote:
In my experience, all the policy-related concepts that one may need
during such a design phase can be described by referring to
PCIM/PCIMe-defined concepts (regardless of the way they are represented,
classes, associations, association classes), ...

<jcs>
I disagree that PCIM/PCIMe has "all" of the policy-related concepts
that I2NSF needs. First, its structure cannot be extended without
significant rework. So, if I2NSF ever does want to examine other
types of policies (e.g., utility functions, intent-based (declarative), or
functional policies), then it is very likely that this would cause the
resulting data models to be completely redone.

Second, PCIM/PCIMe have no notion of events. This means that
many OAM functions cannot trigger an associated security function.
In addition, from a practical point-of-view, events are useful for
deterministic analysis of how security functions work. If you look
at a standard ECA (event-condition-action) policy, then the
purpose of the event clause is to trigger the evaluation of the
condition clause; this makes it much easier to audit, log, and
debug complex security scenarios.

Third, PCIM/PCIMe have no concept of either a Policy Subject
or a Policy Target. The former is vital for deontic and alethic logic
(which I would assume are vital for not just I2NSF, but other
security groups (e.g., SACM)). The later is critical for identifying,
in a scalable manner, which entities are being changed by which
security functions.

I could go on, but I think that these are sufficient.
</jcs>

Aldo wrote:
...concepts that PCIM/PCIMe
miss, and concepts that are not correctly/optimally represented in
PCIM/PCIMe.

<jcs>
Sorry, but my parser seg faulted. :-)
IFF you are saying that everything we need is covered by
what PCIM/PCIMe have and what PCIM/PCIMe don't have,
then this is a logical tautology. If this isn't what you mean,
I'm lost; please explain.
</jcs>

regards,
John

On Wed, Dec 9, 2015 at 3:54 PM, Linda Dunbar <[email-masked]>
wrote:

> Just want to add a note: I2NSF only deals with rule-set/policy for
> treating packets/flows traversing through NSF. Therefore, the I2NSF polices
> would be much simpler, which doesn't need to deal with network wide
> policies or user policies.
>
> Linda
>
>

-- 
regards,
John