John,
Your new definition is good.
To summarize, we have:
1) Consumer-Facing Interface (a.k.a., Client-Facing Interface)
2) NSF-Facing Interface
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.
And you have agreed to drop the “Capability Interface”.
Thanks, Linda
From: John Strassner [mailto:[email protected]]
Sent: Wednesday, October 19, 2016 2:06 PM
To: Linda Dunbar <[email protected]>; John Strassner <[email protected]>
Cc: [email protected]
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.
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 protected]<mailto:[email protected]>> wrote:
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 protected]<mailto:[email protected]>]
Sent: Wednesday, October 19, 2016 2:10 AM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>;
John Strassner <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>]
Sent: Tuesday, October 18, 2016 2:19 PM
To: [email protected]<mailto:[email protected]>
Cc: Linda Dunbar <[email protected]<mailto:[email protected]>>;
Adrian Farrel <[email protected]<mailto:[email protected]>>; John Strassner
<[email protected]<mailto:[email protected]>>
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
--
regards,
John
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
