Subject: Re: [I2nsf] I2NSF Terminology's definition for "Consumer-Facing Interface" is kind of vague

From: John Strassner <[email-masked]>
Date: Thu, 2 Feb 2017 16:02:53 -0800

Dear all,
apologies for the delay, my reply didn't go through and then I was on
travel.
Replies inline, look for <jcs>..<.jcs>

Can I2NSF controller also be the “Consumers of NSF data and services”?

<jcs>

Yes. Recall that we went with "consumer" instead of "client" or "end-user"
because of this reason. The above definition reflects that.

However, in reviewing other dependent definitions, I found that there is a
typo in the definition of Consumer, which may have been why you were
confused. The old definition says, in part:

      A Consumer is a Role that is assigned to an I2NSF
      Component that represents the needs of a user of I2NSF services.

      A consumer can send/receive information to/from another I2NSF
      Component...

It should say:

      A Consumer is a Role that is assigned to an I2NSF
      Component that represents the needs of a user of I2NSF services.

      A consumer can receive and use information from another I2NSF
      Component...

If this doesn't address your concerns, please try and be more specific as
to what is wrong.

</jcs>

Will it be clearer to say that the interface is for expressing users or
tenants (i.e. consumers) oriented policies or rules?

Those policies may not use actual bits carried in data packets as criteria
because packet headers might change when the user’s applications migrate to
different locations.

<jcs>

No, I don't think so. I2NSF is chartered to work on specifying interfaces.
Interfaces require more information than just policies. Put another way, if
we said that the I2NSF Consumer-Facing Interface is **just** for sending
and receiving policies, then:

   1) Why would an I2NSF consumer ever **receive a policy**?

        It could certainly receive data from a policy, or receive indication

        that its policy can't be executed, but both are very different than

        sending the entire policy back, because that implies that the

        consumer has the means to understand what is wrong with the

        policy and to alter it. That's probably fine for controllers, but
not

        for end-users or some types of simple proxies.

  2) This would force the same interface to be used for receiving

        policies and data. That widens the attack surface of policies,

        and risks policy data being overwhelmed by other data.

One of the pain points expressed by the members of the ONUG (Open Network
User Group) Software Defined Security Service group, which primarily
consists of enterprises users, is the “policy lifetime management”, i.e.
they want to be able to specify security policies that won’t need to be
changed when their applications move (from on-premises to cloud, or from
one cloud to another).

<jcs>

Ummmm...

...really? Clearly, if the policy has nothing to do with its environment or
context (e.g., "on 8am, switch to this profile"), then sure. However,
location and connection type are two very important types of context. I
would think that if you change from on-premise to cloud or between clouds,
you would want to change parts of the policy to match the new context. For
example, from a company I used to work for:

   "Only users directly connected to the company Intranet can access code
servers"

In this example, location and connection type are everything.

Another one from OpenStack Congress:

   "Every network attached to a VM must be a public network or a private
network owned by someone in the same group as the VM owner"

Hence, I question the absolute nature of the comment by ONUG. I believe I
am missing context (pun intended).

</jcs>

regards,
John

On Wed, Jan 25, 2017 at 4:25 PM, Linda Dunbar <[email-masked]>
wrote:

> John,
>
>
>
> In the draft-ietf-i2nsf-terminology-02, you have
>
>
>
>
>
>
>
> Can I2NSF controller also be the “Consumers of NSF data and services”?
>
>
>
> Will it be clearer to say that the interface is for expressing users or
> tenants (i.e. consumers) oriented policies or rules?
>
> Those policies may not use actual bits carried in data packets as criteria
> because packet headers might change when the user’s applications migrate to
> different locations.
>
>
>
> One of the pain points expressed by the members of the ONUG (Open Network
> User Group) Software Defined Security Service group, which primarily
> consists of enterprises users, is the “policy lifetime management”, i.e.
> they want to be able to specify security policies that won’t need to be
> changed when their applications move (from on-premises to cloud, or from
> one cloud to another).
>
>
>
> As all other I2NSF drafts depend on the “draft-ietf-i2nsf-terminology”
> being complete (i.e. pass the WGLC), can you find time to address this as
> soon as possible?
>
>
>
> Thank you very much.
>
>
>
> Linda
>
>
>
>
>

-- 
regards,
John