Subject: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

From: Linda Dunbar <[email-masked]>
Date: Thu, 1 Oct 2015 21:32:00 +0000

I2NSF participants,

https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/ specifies the structure for I2NSF capability layer rules.

For the I2NSF simple service layer, what do people think of using OpenStack's Group Policy structure ?

If using OpenStack Group-based Policy (GBP) structure, the I2NSF simple service layer can be expressed as

*        Policy Target Group (PTG). This is a group of Targets to which a traffic policy can be applied. A PTG may be mapped to a Neutron Subnet, a client virtual Subnet (i.e. with private address prefix), a subnet with public address families, or any combination of them with logical operators (Logical AND, OR, or NOT). A PTG references one or more Policy Rule Sets that it consumes or provides.

*        Target. This is used by the application client to establish communications over the network. A Target is mapped to a single Neutron Port, a physical/logical ingress port, or a physical/logical egress port.

*        Policy Rule Set. A Policy Rule Set is used to determine how the traffic between a pair of Target Groups is to be treated. A Policy Rule Set consists of one or more Policy Rules.

*        Policy Rule. A Policy Rule consists of a Traffic Classifier and a set of Actions to be applied to the traffic.

*        Policy Classifier. A traffic classifier describes the traffic to which a Policy Rule is to be applied. It is expressed as a direction, a list of L4 ports, time range, and a protocol.

*        Policy Action. This is the action applied to the traffic that matches the classifier. An action may be a simple ACL action (i.e. allow, deny, mirroring), applying a well known statistics functions (e.g. X minutes count, Y hours court), applying client specified functions (with URL provided), or may refer to an ordered sequence of functions (i.e., a service chain).

If you have concern of using OpenStack Group Based Policies, please let the group know.

Thanks, Linda

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 1 Oct 2015 22:41:07 +0000

Hi Linda,

I am not completely sure that the current networking model of OpenStack, that is reflected in the rule targets (either the PTG and the Target itself) does cover all the potential semantics for general security functions. The same concern applies to Policy Classifier, as they seem very much associated with a particular implementation model and, what is more, with a limited network model.

Be goode,

On 1 Oct 2015, at 23:32 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

I2NSF participants,

For the I2NSF simple service layer, what do people think of using OpenStack’s Group Policy structure ?

If using OpenStack Group-based Policy (GBP) structure, the I2NSF simple service layer can be expressed as
•        Policy Target Group (PTG). This is a group of Targets to which a traffic policy can be applied. A PTG may be mapped to a Neutron Subnet, a client virtual Subnet (i.e. with private address prefix), a subnet with public address families, or any combination of them with logical operators (Logical AND, OR, or NOT). A PTG references one or more Policy Rule Sets that it consumes or provides.
•        Target. This is used by the application client to establish communications over the network. A Target is mapped to a single Neutron Port, a physical/logical ingress port, or a physical/logical egress port.
•        Policy Rule Set. A Policy Rule Set is used to determine how the traffic between a pair of Target Groups is to be treated. A Policy Rule Set consists of one or more Policy Rules.
•        Policy Rule. A Policy Rule consists of a Traffic Classifier and a set of Actions to be applied to the traffic.
•        Policy Classifier. A traffic classifier describes the traffic to which a Policy Rule is to be applied. It is expressed as a direction, a list of L4 ports, time range, and a protocol.
•        Policy Action. This is the action applied to the traffic that matches the classifier. An action may be a simple ACL action (i.e. allow, deny, mirroring), applying a well known statistics functions (e.g. X minutes count, Y hours court), applying client specified functions (with URL provided), or may refer to an ordered sequence of functions (i.e., a service chain).

Thanks, Linda
_______________________________________________
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]
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: Linda Dunbar <[email-masked]>
Date: Fri, 2 Oct 2015 02:08:38 +0000

Diego,

Thank you very much for expressing the opinion.

The “Policy Classifier” of the OpenStack Group Based Policy can be mapped to the “Object” in the I2NSF capability layer rule structure (Subject-Object-Action-Function), where “Object” refers to the  Matching values based on context, e.g. State, direction of the traffic, time, geo-location, etc..

For sure, the current “Policy Classifier” is not comprehensive enough for all the contextual values/events that NSFs can compare.  Maybe I2NSF can use a different terminology to avoid the confusion in the industry, as the OpenStack Group Based Policy (or Window Group Based Policy)  are not enough to describe service layer security policies to networks.  For example, (thinking loud), we can use “Policy – Context” instead.

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, October 01, 2015 5:41 PM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Hi Linda,

Be goode,

I2NSF participants,

Thanks, Linda

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Loa Andersson <[email-masked]>
Date: Fri, 2 Oct 2015 13:17:48 +0800

Linda and Diego,

This is said by someone that is not familiar with Open Stack or the
Group Based Policy.

I'm somewhat on the same page as Diego, at least in the same book.

If we want to use  OpenStack's Group Based Policy to describe I2NSF
Service Layer Rules, the case for this has to be made much better.

What are the pros and cons? Are there viable alternatives?

/Loa

On 2015-10-02 06:41, DIEGO LOPEZ GARCIA wrote:
> Hi Linda,
>
> I am not completely sure that the current networking model of OpenStack,
> that is reflected in the rule targets (either the PTG and the Target
> itself) does cover all the potential semantics for general security
> functions. The same concern applies to Policy Classifier, as they seem
> very much associated with a particular implementation model and, what is
> more, with a limited network model.
>
> Be goode,
>
>
>> https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/specifies
>> the structure for I2NSF capability layer rules.
>> ·Policy Target Group (PTG). This is a group of Targets to which a
>> traffic policy can be applied. A PTG may be mapped to a Neutron
>> Subnet, a client virtual Subnet (i.e. with private address prefix), a
>> subnet with public address families, or any combination of them with
>> logical operators (Logical AND, OR, or NOT). A PTG references one or
>> more Policy Rule Sets that it consumes or provides.
>> ·Target. This is used by the application client to establish
>> communications over the network. A Target is mapped to a single
>> Neutron Port, a physical/logical ingress port, or a physical/logical
>> egress port.
>> ·Policy Rule Set. A Policy Rule Set is used to determine how the
>> traffic between a pair of Target Groups is to be treated. A Policy
>> Rule Set consists of one or more Policy Rules.
>> ·Policy Rule. A Policy Rule consists of a Traffic Classifier and a set
>> of Actions to be applied to the traffic.
>> ·Policy Classifier. A traffic classifier describes the traffic to
>> which a Policy Rule is to be applied. It is expressed as a direction,
>> a list of L4 ports, time range, and a protocol.
>> ·Policy Action. This is the action applied to the traffic that matches
>> the classifier. An action may be a simple ACL action (i.e. allow,
>> deny, mirroring), applying a well known statistics functions (e.g. X
>> minutes count, Y hours court), applying client specified functions
>> (with URL provided), or may refer to an ordered sequence of functions
>> (i.e., a service chain).
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> 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: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 2 Oct 2015 15:28:09 +0000

Exactly, Linda, that was my point: there are several constructs that could reasonably map but that need to be evolved (or can end up being completely misaligned) and that’s why I would refrain from doing a strong commitment to OpenStack, or whatever other project or format, unless:

1) There is a clear, direct and (almost) complete mapping, and
2) It is clear we are in the position of influence is to a reasonable extent (because is used in another IETF WG, for example)

Be goode,

On 2 Oct 2015, at 04:08 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Diego,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, October 01, 2015 5:41 PM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Hi Linda,

Be goode,

I2NSF participants,

Thanks, Linda

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 5 Oct 2015 21:45:53 +0000

Thanks to Loa and Diego for the comments.

Here are some pros and cons of using Open Stack Group Based Policy:

Pros:
*       There are running codes (open sourced code)

Cons:
*       The OpenStack's group based policy is very much Neutron port oriented. It is not straight forward for an environment that is not based on OpenStack Neutron.
*       They are not designed for expressing rules to Flow-based NSF on how to treat client/applications traffic. The current set is not complete,  a lot more need to be added.
*       There are other "Group Based Policy", e.g. Window's Group Policy, which are quite different from the OpenStack's Group Based Policy.
*       May cause confusion in industry if calling "Group Based Policy" for I2NSF Service Layer

However, the notation of Groups, Target, Context 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.  And they can be mapped to the Capability layer's Subject-Object-Action-Function" paradigm.

To avoid the confusion, it might be better to avoid using the term "Group based policy" (but inherent their concept only).

For example, "group" can be represented by "Composite Endpoints/Targets" or Endpoint Container (if using SUPA language), where an "Endpoint" can be a subnet, a set of hosts or applications, etc.

*       Composite Endpoint (CEP).  Logical combination of  endpoint descriptor IDs, where descriptor can be subnet, set of hosts, or applications.

o       Endpoint Descriptor (EPD). Each endpoint descriptor has a type and value that are used to partially identify the endpoint. The type of the Endpoint Descriptor may be a base networking identifier, such as an IP address, or a user-defined type. The value may be a single value, a range of values, or a group of values.

*       Target. This is used by the application client to establish communications over the network. A Target is mapped to a physical/logical ingress port, or a physical/logical egress port.

*       Policy Rule Set. A Policy Rule Set is used to determine how the traffic between a pair of Target Groups is to be treated. A Policy Rule Set consists of one or more Policy Rules.
o       Policy Rule. A Policy Rule consists of a Policy context and a set of Actions to be applied to the traffic.

*       Policy Context. Context that describes when a Policy Rule is to be applied. It is expressed as a direction, a list of L4 ports, time range, and a protocol.

Comments are greatly appreciated.

Linda
-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, October 02, 2015 12:18 AM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Linda and Diego,

This is said by someone that is not familiar with Open Stack or the Group Based Policy.

If we want to use  OpenStack's Group Based Policy to describe I2NSF Service Layer Rules, the case for this has to be made much better.

/Loa

On 2015-10-02 06:41, DIEGO LOPEZ GARCIA wrote:
> Hi Linda,
>
> I am not completely sure that the current networking model of
> OpenStack, that is reflected in the rule targets (either the PTG and
> the Target
> very much associated with a particular implementation model and, what
> is more, with a limited network model.
>
> Be goode,
>
>
>> https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface
>> -im/specifies the structure for I2NSF capability layer rules.
>> If using OpenStack Group-based Policy (GBP) structure, the I2NSF
>> simple service layer can be expressed as ·Policy Target Group (PTG).
>> This is a group of Targets to which a traffic policy can be applied.
>> A PTG may be mapped to a Neutron Subnet, a client virtual Subnet
>> (i.e. with private address prefix), a subnet with public address
>> families, or any combination of them with logical operators (Logical
>> AND, OR, or NOT). A PTG references one or more Policy Rule Sets that
>> it consumes or provides.
>> ·Policy Rule. A Policy Rule consists of a Traffic Classifier and a
>> set of Actions to be applied to the traffic.
>> ·Policy Action. This is the action applied to the traffic that
>> matches the classifier. An action may be a simple ACL action (i.e.
>> allow, deny, mirroring), applying a well known statistics functions
>> (e.g. X minutes count, Y hours court), applying client specified
>> functions (with URL provided), or may refer to an ordered sequence of
>> functions (i.e., a service chain).
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> 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.
>
> 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.
>
> 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,

---

From: Loa Andersson <[email-masked]>
Date: Tue, 6 Oct 2015 16:56:47 +0800

Linda,

How different is "endpoint" from "host" as it used in RFC 1122, RFC 1123
and RFC 5505?

/Loa

On 2015-10-06 05:45, Linda Dunbar wrote:
>   * The OpenStack's group based policy is very much Neutron port
>     oriented. It is not straight forward for an environment that is not
>     based on OpenStack Neutron.
>   * They are not designed for expressing rules to Flow-based NSF on how
>     to treat client/applications traffic. The current set is not
>     complete,  a lot more need to be added.
>   * There are other "Group Based Policy", e.g. Window's Group Policy,
>     which are quite different from the OpenStack’s Group Based Policy.
>   * May cause confusion in industry if calling “Group Based Policy” for
>     I2NSF Service Layer
>
> However, the notation of Groups, Target, Context 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. And they
> can be mapped to the Capability layer’s Subject-Object-Action-Function”
> paradigm.
> To avoid the confusion, it might be better to avoid using the term
> “Group based policy” (but inherent their concept only).
> For example, “group” can be represented by “Composite Endpoints/Targets”
> or Endpoint Container (if using SUPA language), where an “Endpoint” can
> be a subnet, a set of hosts or applications, etc.
>
>   * Composite Endpoint (CEP). Logical combination of endpoint descriptor
>     IDs, where descriptor can be subnet, set of hosts, or applications.
>
>   * Endpoint Descriptor (EPD). Each endpoint descriptor has a type and
>     value that are used to partially identify the endpoint. The type of
>     the Endpoint Descriptor may be a base networking identifier, such as
>     an IP address, or a user-defined type. The value may be a single
>     value, a range of values, or a group of values.
>
>   * Target. This is used by the application client to establish
>     communications over the network. A Target is mapped to a
>     physical/logical ingress port, or a physical/logical egress port.
>
>   * Policy Rule Set. A Policy Rule Set is used to determine how the
>   * Policy Rule. A Policy Rule consists of a Policy context and a set of
>     Actions to be applied to the traffic.
>
>   * Policy Context. Context that describes when a Policy Rule is to be
>     applied. It is expressed as a direction, a list of L4 ports, time
>     range, and a protocol.
>
>   * Policy Action. This is the action applied to the traffic that
>     functions (with URL provided), or may refer to an ordered sequence
>     of functions (i.e., a service chain).
>
> Subject: Re: [I2nsf] What do you people think of using OpenStack's Group
> Based Policy to describe I2NSF Service Layer Rules?
> Linda and Diego,
>>>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>> e-mail:[email-masked] <mailto:[email-masked]>
>> Tel:    +34 913 129 041
>> Mobile: +34 682 051 091

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 6 Oct 2015 11:07:08 +0000

Hi Linda,

I have been talking about this with one of the policy experts in the SECURED project (Aldo Basile, I have put him in Cc: so you can identify him, though he is in the I2NSF list as well…) and these are his comments:

8<—

In my understanding, OpenStack Group Policies are a simplified yet generic way to associate iptables-like rules, the syntax is very similar.
It is network management rather then security management. You can express simple network policies (commands) and associate to network nodes and groups.

GBP is not a generic framework for expressing policies.
Something is general (like the definition of rules as (classifier,action)) but it requires several extensions that, in the end, when completed will lead to PCIM or SG17-like models.

Thus, in my opinion, SG17/PCIM are certainly a better starting point, and also easier to push SECURED results.

"Policy Classifier" is another way to tell 'matching conditions' (as networking people likes the word classifier, for me a classifier is something more intelligent).

Conditions available on OpenStack Group Policies are now a very limited subset of l4 filtering (they don't even cover packet filters). However, the model (condition,action) is general enough to cope with future needs (by adding more classifiers).

There is no way to categorize policies (thus no capabilities no easy link to NSF categorization for interoperability).

Then, no resolution strategies, no default actions, no priorities, no other sophisticated ways to express policies.

8<—

I’ll let Aldo to express his views in more detail, but my position is that we should consider an existing general framework as starting point, and that PCIM (see http://www.dmtf.org/standards/policy) is the most promising one.

Be goode,

On 5 Oct 2015, at 23:45 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Pros:

Cons:

  *   The OpenStack's group based policy is very much Neutron port oriented. It is not straight forward for an environment that is not based on OpenStack Neutron.
  *   They are not designed for expressing rules to Flow-based NSF on how to treat client/applications traffic. The current set is not complete,  a lot more need to be added.
  *   There are other "Group Based Policy", e.g. Window's Group Policy, which are quite different from the OpenStack’s Group Based Policy.
  *   May cause confusion in industry if calling “Group Based Policy” for I2NSF Service Layer

However, the notation of Groups, Target, Context 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. And they can be mapped to the Capability layer’s Subject-Object-Action-Function” paradigm.

To avoid the confusion, it might be better to avoid using the term “Group based policy” (but inherent their concept only).

For example, “group” can be represented by “Composite Endpoints/Targets” or Endpoint Container (if using SUPA language), where an “Endpoint” can be a subnet, a set of hosts or applications, etc.

  *   Endpoint Descriptor (EPD). Each endpoint descriptor has a type and value that are used to partially identify the endpoint. The type of the Endpoint Descriptor may be a base networking identifier, such as an IP address, or a user-defined type. The value may be a single value, a range of values, or a group of values.

  *   Policy Rule. A Policy Rule consists of a Policy context and a set of Actions to be applied to the traffic.

Linda
-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, October 02, 2015 12:18 AM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Linda and Diego,

/Loa

On 2015-10-02 06:41, DIEGO LOPEZ GARCIA wrote:
>> On 1 Oct 2015, at 23:32 , Linda Dunbar <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]>> wrote:
>>
>> I2NSF participants,

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 6 Oct 2015 15:56:46 +0000

Diego: Thank you very much for relaying Aldo's comments. That is very useful.

Aldo: Can you suggest some references for the "Security Management"?

Bear in mind that I2NSF is not to tackle the general policies (which belongs to SUPA WG).
I2NSF is to open a hole for clients/applications to inform to Flow-based NSFs to inform them the rules for treating traffic traversing through.

Using PCIM (RFC3060 which the ITU-T X.1036 was based on) as a basis would be a good idea. However, RFC3060 was created for general network policies for Directory Enabled Network, in some aspects more than what I2NSF needs, and in other aspects needs extension. Especially need extension on the Policy Context (i.e. the directions, the time, and other contextual events that governs the policies to NSFs). E.g.

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Tuesday, October 06, 2015 6:07 AM
To: Linda Dunbar
Cc: Loa Andersson; Aldo Basile; [email-masked]
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Hi Linda,

I have been talking about this with one of the policy experts in the SECURED project (Aldo Basile, I have put him in Cc: so you can identify him, though he is in the I2NSF list as well...) and these are his comments:

8<-

8<-

I'll let Aldo to express his views in more detail, but my position is that we should consider an existing general framework as starting point, and that PCIM (see http://www.dmtf.org/standards/policy) is the most promising one.

Be goode,

Pros:
·        There are running codes (open sourced code)

Cons:
·        The OpenStack's group based policy is very much Neutron port oriented. It is not straight forward for an environment that is not based on OpenStack Neutron.
·        They are not designed for expressing rules to Flow-based NSF on how to treat client/applications traffic. The current set is not complete,  a lot more need to be added.
·        There are other "Group Based Policy", e.g. Window's Group Policy, which are quite different from the OpenStack's Group Based Policy.
·        May cause confusion in industry if calling "Group Based Policy" for I2NSF Service Layer

·        Composite Endpoint (CEP). Logical combination of endpoint descriptor IDs, where descriptor can be subnet, set of hosts, or applications.

·        Endpoint Descriptor (EPD). Each endpoint descriptor has a type and value that are used to partially identify the endpoint. The type of the Endpoint Descriptor may be a base networking identifier, such as an IP address, or a user-defined type. The value may be a single value, a range of values, or a group of values.

·        Target. This is used by the application client to establish communications over the network. A Target is mapped to a physical/logical ingress port, or a physical/logical egress port.

·        Policy Rule Set. A Policy Rule Set is used to determine how the traffic between a pair of Target Groups is to be treated. A Policy Rule Set consists of one or more Policy Rules.
·        Policy Rule. A Policy Rule consists of a Policy context and a set of Actions to be applied to the traffic.

·        Policy Context. Context that describes when a Policy Rule is to be applied. It is expressed as a direction, a list of L4 ports, time range, and a protocol.

·        Policy Action. This is the action applied to the traffic that matches the classifier. An action may be a simple ACL action (i.e. allow, deny, mirroring), applying a well known statistics functions (e.g. X minutes count, Y hours court), applying client specified functions (with URL provided), or may refer to an ordered sequence of functions (i.e., a service chain).

Linda
-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, October 02, 2015 12:18 AM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Linda and Diego,

/Loa

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 6 Oct 2015 16:10:05 +0000

Loa, 

The "Composite Endpoint" in the context includes the group of hosts used by RFC1122/1123/5505, group of applications, types of applications, user defined types, or specific client traffic. 

Agree with you that the terminology "End point" (taken from one of the proposals to OpenStack) doesn't represent the concept well. Do you have better suggestions? 

Linda 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, October 06, 2015 3:57 AM
To: Linda Dunbar; DIEGO LOPEZ GARCIA
Cc: [email-masked]
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Linda,

How different is "endpoint" from "host" as it used in RFC 1122, RFC 1123 and RFC 5505?

/Loa

On 2015-10-06 05:45, Linda Dunbar wrote:
>     which are quite different from the OpenStack's Group Based Policy.
> their flows can be treated by the Flow-Based NSFs in networks. And 
> they can be mapped to the Capability layer's Subject-Object-Action-Function"
> paradigm.
> "Group based policy" (but inherent their concept only).
> For example, "group" can be represented by "Composite Endpoints/Targets"
> or Endpoint Container (if using SUPA language), where an "Endpoint" 
> can be a subnet, a set of hosts or applications, etc.
>
> Subject: Re: [I2nsf] What do you people think of using OpenStack's 
> Group Based Policy to describe I2NSF Service Layer Rules?
> Linda and Diego,
>> functions. The same concern applies to Policy Classifier, as they 
>> seem very much associated with a particular implementation model and, 
>> what is more, with a limited network model.
>>
>> Be goode,
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> destinatario, puede contener información privilegiada o confidencial 
>> y es para uso exclusivo de la persona o entidad de destino. Si no es

---

From: Loa Andersson <[email-masked]>
Date: Wed, 7 Oct 2015 02:19:53 +0800

Linda,

While I understand (somewhat) where you are going e.g. with group of
applications, types of applications, etc. The fact that those
applications or functions may reside in one or more "hosts" seem to
have very small impact on the model. If they are end-points they are
hosts, right?

We were over all that in the L2VPN work, maybe time to re-read.

/Loa

---

From: Youjianjie <[email-masked]>
Date: Wed, 7 Oct 2015 04:10:05 +0000

Hi all,

Since we're talking about group based policy, I'm going to submit an internet-draft about 'User-group based Mechanism for Service Layer' to this IETF meeting. The main idea is as follows:

The draft discusses enterprise use case and requirements for user-group based security policy that allows users to enjoy the consistent policy and experience on the entire network regardless of user or resource location. A User-group Aware Policy Control (UAPC) is proposed to decouple users from IP addresses or VLANs so that users can move and remain connected with unified policies.

The UAPC is based on logical groups, which are decoupled from IP addresses, so only the relationship between two logical groups needs to be considered when planning group policies. On the controller, the administrator can use a policy matrix to configure user group policies. For example, the following table shows the inter-group policies.

                      Destination Group
------------------------------------------------------------------------------------------------------------------------
Source Group	 Workflow Server 	R&D Resource Server 	Sales Resource Server 
------------------------------------------------------------------------------------------------------------------------
R&D group 	    Permit 	     Permit 	              Deny
Sales group 	    Permit 	     Deny 	              Permit
VIP user group 	Permit 	     Permit 	              Permit

Please let me know if you have any comments.

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: I2nsf [mailto:[email-masked]] 代表 Loa Andersson
> 发送时间: 2015年10月7日 2:20
> 收件人: Linda Dunbar; DIEGO LOPEZ GARCIA
> 抄送: [email-masked]
> 主题: Re: [I2nsf] What do you people think of using OpenStack's Group Based
> Policy to describe I2NSF Service Layer Rules?
> 
> Linda,
> 
> applications, types of applications, etc. The fact that those applications or
> functions may reside in one or more "hosts" seem to have very small impact on
> the model. If they are end-points they are hosts, right?
> 
> > The "Composite Endpoint" in the context includes the group of hosts used by
> RFC1122/1123/5505, group of applications, types of applications, user defined
> types, or specific client traffic.
> >
> > Agree with you that the terminology "End point" (taken from one of the
> proposals to OpenStack) doesn't represent the concept well. Do you have
> better suggestions?
> >
> > Linda
> >
> >
> >>> seem very much associated with a particular implementation model
> >>> and, what is more, with a limited network model.
> >>>
> >>> Be goode,
> >>>
> >>>
> >>>> https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interfa
> >>>> ce -im/specifies the structure for I2NSF capability layer rules.
> >>>> families, or any combination of them with logical operators
> >>>> (Logical AND, OR, or NOT). A PTG references one or more Policy Rule
> >>>> Sets that it consumes or provides.
> >>>> Neutron Port, a physical/logical ingress port, or a
> >>>> physical/logical egress port.
> >>>> which a Policy Rule is to be applied. It is expressed as a
> >>>> direction, a list of L4 ports, time range, and a protocol.
> >>> mensaje por error, le rogamos que nos lo comunique inmediatamente
> >>> por esta misma vía y proceda a su destrucción.
> >>>
> >>> 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: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 8 Oct 2015 07:26:54 +0000

Hi all,
My understanding is that PCIM/SG17 is mainly related to the syntax of the information model, and is possible to be a starting point.
In addition, the other important point we need to consider is the semantic aspects of the information model: which contents can be in the security rule and in which way they are categorized and organized?
There are many possible ways, such as: “5W1H”, “subject-object-action-function”, hierarchical processing, or combination of them.

Comments are greatly appreciated!

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 DIEGO LOPEZ GARCIA
发送时间: 2015年10月6日 19:07
收件人: Linda Dunbar
抄送: [email-masked]; Aldo Basile; Loa Andersson
主题: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Hi Linda,

8<—

8<—

Be goode,

Pros:

Cons:
·         The OpenStack's group based policy is very much Neutron port oriented. It is not straight forward for an environment that is not based on OpenStack Neutron.
·         They are not designed for expressing rules to Flow-based NSF on how to treat client/applications traffic. The current set is not complete,  a lot more need to be added.
·         There are other "Group Based Policy", e.g. Window's Group Policy, which are quite different from the OpenStack’s Group Based Policy.
·         May cause confusion in industry if calling “Group Based Policy” for I2NSF Service Layer

Linda
-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, October 02, 2015 12:18 AM
To: DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Linda and Diego,

/Loa

Dr Diego R. Lopez
Telefonica I+D

---

From: Aldo Basile <[email-masked]>
Date: Thu, 8 Oct 2015 17:06:30 +0200

Dear Linda,

first of all sorry for the very late reply, and thanks Diego for 
introducing me (and presenting me as a 'policy expert').

I admit there is not a lot of good literature on Security Management (I 
assume Policy-based Security Management or Policy-Based Network Security 
Management, which is a relatively narrow field). I'm listing here some 
works but I'm sure you already know all of them.

1) Most of the works start from the Strassner definition of Policy-based 
Network Management (PBNM). Strassner introduced the idea of 'policy 
continuum' and developed the DEN-ng architecture.

Here a set of links to Strassner's papers:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.495.4361&rep=rep1&type=pdf
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1015622&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1015622

He also published a book (which I didn't read):
http://dl.acm.org/citation.cfm?id=1206794

2) Then, I know this work from an IBM fellow that tries to map and 
organize PBNM concepts on the security field
http://researchweb.watson.ibm.com/people/d/dverma/papers/NetMgmtPolicy.pdf

3) Then there are the RFC3198 and the PCIM series (RFC 3060, now RFC 3460).

No recent works though. Apparently, this research field has moved from 
academia to industry.

Please let me know if you further details or if I didn't interpret 
correctly the "Security Management" field.

Regards,
Aldo

On 06/10/2015 17:56, Linda Dunbar wrote:
> Diego: Thank you very much for relaying Aldo’s comments. That is very
> useful.
>
> Aldo: Can you suggest some references for the “Security Management”?
>
> I2NSF is to open a hole for clients/applications to inform to Flow-based
> NSFs to inform them the rules for treating traffic traversing through.
>
> Using PCIM (RFC3060 which the ITU-T X.1036 was based on) as a basis
> would be a good idea. However, RFC3060 was created for general network
> policies for Directory Enabled Network, in some aspects more than what
> I2NSF needs, and in other aspects needs extension. Especially need
> extension on the Policy Context (i.e. the directions, the time, and
> other contextual events that governs the policies to NSFs). E.g.
>
> *From:*DIEGO LOPEZ GARCIA [mailto:[email-masked]]
> *Sent:* Tuesday, October 06, 2015 6:07 AM
> *To:* Linda Dunbar
> *Cc:* Loa Andersson; Aldo Basile; [email-masked]
> *Subject:* Re: [I2nsf] What do you people think of using OpenStack's
> I have been talking about this with one of the policy experts in the
> SECURED project (Aldo Basile, I have put him in Cc: so you can identify
> him, though he is in the I2NSF list as well…) and these are his comments:
>
> 8<—
>
>     In my understanding, OpenStack Group Policies are a simplified yet
>     generic way to associate iptables-like rules, the syntax is very
>     similar.
>     It is network management rather then security management. You can
>     express simple network policies (commands) and associate to network
>     nodes and groups.
>
>     Something is general (like the definition of rules as
>     (classifier,action)) but it requires several extensions that, in the
>     end, when completed will lead to PCIM or SG17-like models.
>
>     Thus, in my opinion, SG17/PCIM are certainly a better starting
>     point, and also easier to push SECURED results.
>
>     "Policy Classifier" is another way to tell 'matching conditions' (as
>     networking people likes the word classifier, for me a classifier is
>     something more intelligent).
>
>     Conditions available on OpenStack Group Policies are now a very
>     limited subset of l4 filtering (they don't even cover packet
>     filters). However, the model (condition,action) is general enough to
>     cope with future needs (by adding more classifiers).
>
>     There is no way to categorize policies (thus no capabilities no easy
>     link to NSF categorization for interoperability).
>
>     Then, no resolution strategies, no default actions, no priorities,
>     no other sophisticated ways to express policies.
>
> 8<—
>
> I’ll let Aldo to express his views in more detail, but my position is
> that we should consider an existing general framework as starting point,
> and that PCIM (see http://www.dmtf.org/standards/policy) is the most
> promising one.
>
> Be goode,
>
>     ·There are running codes (open sourced code)
>
>     Cons:
>
>     ·The OpenStack's group based policy is very much Neutron port
>     ·They are not designed for expressing rules to Flow-based NSF on how
>     ·There are other "Group Based Policy", e.g. Window's Group Policy,
>     ·May cause confusion in industry if calling “Group Based Policy” for
>     I2NSF Service Layer
>
>     they can be mapped to the Capability layer’s
>     Subject-Object-Action-Function” paradigm.
>
>     For example, “group” can be represented by “Composite
>     Endpoints/Targets” or Endpoint Container (if using SUPA language),
>     where an “Endpoint” can be a subnet, a set of hosts or applications,
>     etc.
>
>     ·Composite Endpoint (CEP). Logical combination of endpoint
>     descriptor IDs, where descriptor can be subnet, set of hosts, or
>     applications.
>
>     ·Endpoint Descriptor (EPD). Each endpoint descriptor has a type and
>     ·Policy Rule. A Policy Rule consists of a Policy context and a set
>     ·Policy Context. Context that describes when a Policy Rule is to be
>     Cc:[email-masked] <mailto:[email-masked]>
>     >> On 1 Oct 2015, at 23:32 , Linda Dunbar <[email-masked] <mailto:[email-masked]>
>
>     >> For the I2NSF simple service layer, what do people think of using
>
>     >> OpenStack’s Group Policy structure ?
>
>     >> If you have concern of using OpenStack Group Based Policies, please
>
>     >> let the group know.
>
>     >> Thanks, Linda
>
>     >>[email-masked] <mailto:[email-masked]><mailto:[email-masked]>
>
>     > ----------------------------------------------------------------------
>
>     > --
>
>     >
>
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091

---

From: Aldo Basile <[email-masked]>
Date: Thu, 8 Oct 2015 17:17:11 +0200

Dear all,

my 2 cents... in a long boring email...

I agree on the Frank Xialiang comment on the need for a clear 
specification of the semantics. However, semantics must is a meta-layer 
built on the syntax.

In my opinion, PCIM is more than enough to express the syntax of network 
level policies (while it is not flexible enough for general policies). 
So PCIM can be a valid starting point. Moreover, on paper, PCIM has been 
designed also to cope with event-based architectures, which are often 
needed for sophisticated management.

After several analyses, I pushed to adopt it in three of the projects 
where I worked and in the end we were satisfied by its flexibility and 
expressiveness.

There is one more thing to consider, as PCIM is part of CIM, it is 
possible to borrow, from that incredibly huge framework, classes and 
associations to describe NSFs and their parts (extensions will be 
certainly needed, but all network components are almost there).
As far as I remember, the CIM parts about virtualization are not mature 
enough (I checked a couple of years ago). Thus, in a previous project 
we decided to borrow concepts from libvirt.
[I don't know if this can be interesting to I2NSF, I imagine it is a 
completely different scenario]

Unfortunately, PCIM is not perfect and in my opinion it has some 
inconsistency, probably due to difficulties in reconciling the needs 
from different vendors (my favourite example is the introduction of the 
FilterEntry/FilterList classes).

---
After having read (guess) all the I2NSF-related drafts, I like the idea 
of using a Subject-Object-Function-Action paradigm to add the needed 
semantics (draft-lopez-i2nsf-packet-00).

Because, in the end (but correct me if I'm wrong), some of the core 
problems I2NSF wants to address are:
1) determining what an NSF can do for implementing my security 
requirements, and
2) generating a configuration that NSFs can properly consume.
"Software interfaces and data models for controlling and monitoring 
aspects of physical and virtual NSFs" could be built on top of the 
results to achieve these two points.

Thus, in my understanding,
- an Action determines what an NSFs can do for me (in a packets-based 
paradigm)
- Subjects (which are named 'Match' in the Xie draft) are in my 
understanding stateless conditions (available in the rules to select the 
packets to which actions apply).
- Objects are stateful conditions (at all ISO/OSI stack layers)
- Functions are NSF specific properties. I'm not sure how Functions 
relate to Subjects, Objects, and Actions (if they may be one of the 
three aspects or a separate concepts). In case Functions may also be

All these concepts can be mapped (with limited effort) on PCIM. 
PolicyVariables can be associated to functionality to characterize 'what 
an NSF can do for me', thus semantics and NSF identification with a sort 
of capability matching.

The same consideration applies to the Xie proposal 
(draft-xia-i2nsf-capability-interface-im-02), the proposed "Overall 
Information Model for I2NSF Capability Interface" seems to me easily 
mappable on PCIM conditions and actions (again, with limited effort).

By following your discussions, I'll also try to better understand what 
you exactly mean with "Context" and its relations to stateful conditions 
and their verification.
I don't remember (by heart, but I need to check) some standards to 
describe this information. That is, I don't remember any other 
(network-level) security standard/format/language properly covering 
stateful data management and relations with packet matching.

As you noticed, I tend to write to much and I tend to invade spaces that 
are not mine with absolute judgments and suggestions. So, just take it 
my personal opinion as I really don't want to affect any decision in 
this working group.
I only hope I can be useful in providing you information, as I had to 
deal with similar problems in the past.

Regards,
Aldo

On 08/10/2015 09:26, Xialiang (Frank) wrote:
> Hi all,
>
> My understanding is that PCIM/SG17 is mainly related to the syntax of
> the information model, and is possible to be a starting point.
>
> In addition, the other important point we need to consider is the
> semantic aspects of the information model: which contents can be in the
> security rule and in which way they are categorized and organized?
>
> There are many possible ways, such as: “5W1H”,
> “subject-object-action-function”, hierarchical processing, or
> combination of them.
>
> *发件人:*I2nsf [mailto:[email-masked]] *代表 *DIEGO LOPEZ GARCIA
> *发送时间:*2015年10月6日19:07
> *收件人:*Linda Dunbar
> *抄送:[email-masked]; Aldo Basile; Loa Andersson
> *主题:*Re: [I2nsf] What do you people think of using OpenStack's Group

---

From: Loa Andersson <[email-masked]>
Date: Fri, 9 Oct 2015 14:41:13 +0800

Aldo,

PCIM is a "in house product", right? SO if we have something that is
"more than enough" it is hard to why that should not be used.

/Loa

On 2015-10-08 23:17, Aldo Basile wrote:
> enough (I checked a couple of years ago). Thus, in a previous project we
> decided to borrow concepts from libvirt.
>> (Logical
>> physical/logical
>> direction,
>> <mailto:[email-masked]>
>> Tel:    +34 913 129 041
>> Mobile: +34 682 051 091

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 10 Oct 2015 20:36:49 +0000

Aldo, 

Thank you very much for the detailed analysis. Hope some of your in-depth analysis can be captured in I2NSF drafts, so that we won't forget.  

Just a comment, the "Context" used by Capability Information model includes the "State". 

I will let John Strassner to comment on how to trim PMIC for I2NSF purpose and what to add. 

Linda

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]] 
Sent: Thursday, October 08, 2015 10:17 AM
To: Xialiang (Frank); DIEGO LOPEZ GARCIA; Linda Dunbar
Cc: [email-masked]; Loa Andersson
Subject: Re: [I2nsf] 答复: What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Dear all,

---

Regards,
Aldo

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 10 Oct 2015 20:36:51 +0000

Aldo, 

Thank you very much for the links. They are very helpful. 

Linda

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]] 
Sent: Thursday, October 08, 2015 10:07 AM
To: Linda Dunbar; DIEGO LOPEZ GARCIA
Cc: [email-masked]; Loa Andersson
Subject: Re: [I2nsf] What do you people think of using OpenStack's Group Based Policy to describe I2NSF Service Layer Rules?

Dear Linda,

Regards,
Aldo