Subject: [I2nsf] Need two different names: One for the Set of rules with Users/tenants oriented attributes; another for Set of rules that are applied to NSFs (i.e. port/addresses based).

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Oct 2016 15:18:07 +0000

John,

All we need is to have two different names to differentiate
-        Set of rules with Users/tenants oriented attributes
-        Set of rules that are applied to NSFs (i.e. port/addresses based).

Consumer facing and NSF facing would be good, but with the definition for “Consumer” in the terminology draft , “consumer” can also mean controller consuming NSFs (i.e. the NSF facing interface).  If we use the “consumer facing interface”, can you modify the definition for “consumer”?

   Consumer:  A Consumer is a Role that is assigned to an I2NSF
      Component that can receive information from another I2NSF
      Component.  See also:  Provider, Role.

Thanks, Linda

From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, October 19, 2016 2:10 AM
To: Linda Dunbar <[email-masked]>; John Strassner <[email-masked]>
Subject: Re: you could be correct, but we are dealing with a group of people who commonly interpret "Interface" as "port"

I'm confused.

There is no argument about Consumer-Facing and NSF-Facing Interfaces.
Do you want two different names for the Capability Interface, one for Consumer-Facing and one for NSF-Facing Interfaces? Or do you want something else?

I am troubled that the list is silent.

regards,
John

On Tue, Oct 18, 2016 at 6:27 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John,

You can be correct. But the Interim meeting, most people expressed the desire of using “interface” to mean the “port” on the controller: one port facing user (i.e. the User/client facing interface), another port facing NSFs (NSF-Facing interface).

Sept 13 meeting minutes:
Final agreement: We

Two interfaces
- Consumer/Client Facing Interface
- NSF Facing Interface
Within these we have "sets of operations"
One of these sets is the "Capabilities set of operations"

At the time I didn’t realize that “consumer” also applicable to “Controller” consuming the NSFs. That is why I want to use a different term.

All we need is to have two different names to differentiate

-        Set of rules with Users/tenants oriented attributes

-        Set of rules that are applied to NSFs (i.e. port/addresses based).

Let’s use have two names and move forward.

Can you give me a call?

Thanks, Linda

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 18, 2016 2:19 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: The (in)famous Capability Interface

Hi all,

recently, a number of questions have been raised about the Capability Interface. There are two sources of confusion:

   1) What, exactly, is an "interface"? Can we use a different word instead of interface?
   2) Why do we need another interface (or similar word)?

Clarifying the first issue.
A number of people have stated that to them, an "interface" is synonymous with "communication". This is NOT what was meant when this I-D was written. Indeed, the definition of Interface, from that I-D, is as follows:

   Interface:  A set of operations one object knows it can invoke on,
      and expose to, another object.  It is a subset of all operations
      that a given object implements.  The same object may have multiple
      types of interfaces to serve different purposes.  An example of
      multiple interfaces can be seen by considering the interfaces
      include a firewall uses; these include:
         *  multiple interfaces for data packets to traverse through,
         *  an interface for a controller to impose policy, or retrieve
            the results of execution of a policy rule.
      See also: Consumer Interface, I2NSF Interface, Provider Interface

Note that the above definition implies a **shared boundary** across which two entities send and/or receive data. In other words, what's important is the set of standard operations that can be invoked, and **not** the fact that this is a form of communication.

Clarifying the second issue.
The reason that a separate interface for exchanging capability information was proposed is to minimize the attack surface. The capability interface is for exchanging **all** capabilities, so that two entities may negotiate and agree on what set of capabilities will actually be used. Clearly, this is different than operation on either the consumer-facing or NSF-facing interfaces, since those interfaces are constrained to using **only** the set of capabilities that have been agreed upon to use. This follows the well-known Principle of Least Privilege (i.e., in a particular abstraction, every function must be able to access **only** the information and resources that are necessary for the legitimate purpose of that function.

Exposing the set of **all** capabilities over a widely used interface (like the consumer- or NSF-facing interfaces) is a **bad idea**. It risks an attacker understanding the complete set of capabilities of the system. Furthermore, from a software componentization point-of-view, there is a significant difference between exposing and negotiating between the set of all capabilities (which is the purpose of the Capability Interface) and simply using a selected set of capabilities (which is the purpose of the consumer-facing or NSF-facing interfaces).

I hope this clarifies these two issues. I'll wait a couple of days before issuing the next update to the Terminology Draft.

best regards,
John

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Oct 2016 12:05:51 -0700

Hi Linda,

the original question was about the **Capability Interface**. I'm not sure
that this is what you are talking about, so let me be explicit.

The original architecture had four interfaces:

   1) Consumer-Facing Interface (a.k.a., Client-Facing Interface)
   2) NSF-Facing Interface
   3) Capability Interface
   4) Registration Interface

I **like** these four interfaces, because they each serve different
purposes (ref: Single Responsibility Principle, among others, in software
architecture).

Now it appears that you are no longer talking about the Capability
Interface; rather, you want to change the definition of Consumer to clarify
that it is acting between end-users of the I2NSF system and the controller.
Assuming that this is correct, how about the following modification:

   Consumer:  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 (e.g., for defining and monitoring security policies
      for the Consumer's specific flows through an I2NSF
      administrative domain).  See also:  Provider, Role.

regards,
John

On Wed, Oct 19, 2016 at 8:18 AM, Linda Dunbar <[email-masked]>
wrote:

> Consumer facing and NSF facing would be good, but with the definition for
> “Consumer” in the terminology draft , “consumer” can also mean controller
> consuming NSFs (i.e. the NSF facing interface).  If we use the “consumer
> facing interface”, can you modify the definition for “consumer”?
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Wednesday, October 19, 2016 2:10 AM
> *To:* Linda Dunbar <[email-masked]>; John Strassner <
> [email-masked]>
> *Subject:* Re: you could be correct, but we are dealing with a group of
> people who commonly interpret "Interface" as "port"
>
>
>
> I'm confused.
>
>
>
> Do you want two different names for the Capability Interface, one for
> Consumer-Facing and one for NSF-Facing Interfaces? Or do you want something
> else?
>
>
>
> On Tue, Oct 18, 2016 at 6:27 PM, Linda Dunbar <[email-masked]>
> wrote:
>
> John,
>
>
>
> You can be correct. But the Interim meeting, most people expressed the
> desire of using “interface” to mean the “port” on the controller: one port
> facing user (i.e. the User/client facing interface), another port facing
> NSFs (NSF-Facing interface).
>
>
>
> Sept 13 meeting minutes:
>
> Final agreement: We
>
>
>
> Two interfaces
>
> At the time I didn’t realize that “consumer” also applicable to
> “Controller” consuming the NSFs. That is why I want to use a different
> term.
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Tuesday, October 18, 2016 2:19 PM
> *To:* [email-masked]
> *Cc:* Linda Dunbar <[email-masked]>; Adrian Farrel <
> [email-masked]>; John Strassner <[email-masked]>
> *Subject:* The (in)famous Capability Interface
>
>
>
> Hi all,
>
>
>
> recently, a number of questions have been raised about the Capability
> Interface. There are two sources of confusion:
>
>
>
> A number of people have stated that to them, an "interface" is synonymous
> with "communication". This is NOT what was meant when this I-D was written.
> Indeed, the definition of Interface, from that I-D, is as follows:
>
>
>
> Note that the above definition implies a **shared boundary** across which
> two entities send and/or receive data. In other words, what's important is
> the set of standard operations that can be invoked, and **not** the fact
> that this is a form of communication.
>
>
>
> The reason that a separate interface for exchanging capability information
> was proposed is to minimize the attack surface. The capability interface is
> for exchanging **all** capabilities, so that two entities may negotiate and
> agree on what set of capabilities will actually be used. Clearly, this is
> different than operation on either the consumer-facing or NSF-facing
> interfaces, since those interfaces are constrained to using **only** the
> set of capabilities that have been agreed upon to use. This follows the
> well-known Principle of Least Privilege (i.e., in a particular abstraction,
> every function must be able to access **only** the information and
> resources that are necessary for the legitimate purpose of that function.
>
>
>
> Exposing the set of **all** capabilities over a widely used interface
> (like the consumer- or NSF-facing interfaces) is a **bad idea**. It risks
> an attacker understanding the complete set of capabilities of the system.
> Furthermore, from a software componentization point-of-view, there is a
> significant difference between exposing and negotiating between the set of
> all capabilities (which is the purpose of the Capability Interface) and
> simply using a selected set of capabilities (which is the purpose of the
> consumer-facing or NSF-facing interfaces).
>
>
>
> I hope this clarifies these two issues. I'll wait a couple of days before
> issuing the next update to the Terminology Draft.
>
>
>
> best regards,
>
> John
>
> --
>
> regards,
>
> John
>
>
>
>
> --
>
> regards,
>
> John
>

-- 
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 19 Oct 2016 21:43:48 +0000

John,

Your new definition is good.

To summarize, we have:

And you have agreed to drop the “Capability Interface”.

Thanks, Linda

From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, October 19, 2016 2:06 PM
To: Linda Dunbar <[email-masked]>; John Strassner <[email-masked]>
Cc: [email-masked]
Subject: Re: Need two different names: One for the Set of rules with Users/tenants oriented attributes; another for Set of rules that are applied to NSFs (i.e. port/addresses based).

Hi Linda,

the original question was about the **Capability Interface**. I'm not sure that this is what you are talking about, so let me be explicit.

I **like** these four interfaces, because they each serve different purposes (ref: Single Responsibility Principle, among others, in software architecture).

Now it appears that you are no longer talking about the Capability Interface; rather, you want to change the definition of Consumer to clarify that it is acting between end-users of the I2NSF system and the controller. Assuming that this is correct, how about the following modification:

regards,
John

On Wed, Oct 19, 2016 at 8:18 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John,

Thanks, Linda

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 19, 2016 2:10 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: Re: you could be correct, but we are dealing with a group of people who commonly interpret "Interface" as "port"

I'm confused.

regards,
John

Sept 13 meeting minutes:
Final agreement: We

Two interfaces

Can you give me a call?

Thanks, Linda

Hi all,

best regards,
John

--
regards,
John

--
regards,
John

--
regards,
John