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

[John Strassner <[e-mail]>]

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 <[e-mail]>
wrote:

> 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:[e-mail]]
> Sent: Wednesday, December 09, 2015 5:43 AM
> To: DIEGO LOPEZ GARCIA; Linda Dunbar
> Cc: [e-mail]; John Strassner
> Subject: Re: [I2nsf] Service Layer Policies - Post 0: note structure
>
> 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,
> >
> >> On 7 Dec 2015, at 22:25 , Linda Dunbar <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >> 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:[e-mail]]*On Behalf Of*John
> Strassner
> >> *Sent:*Sunday, December 06, 2015 7:00 PM
> >> *To:*[e-mail] <mailto:[e-mail]>
> >> *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 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
> >> _______________________________________________
> >> I2nsf mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> 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: [e-mail] <mailto:
> [e-mail]>
> > Tel:    [phone]
> > Mobile: [phone]
> > ----------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
> > 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
> >
> >
> > _______________________________________________
> > I2nsf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i2nsf
> >
>
>
>


-- 
regards,
John