Subject: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Sep 2016 17:27:56 +0000

As the I2NSF Terminology has defined two types of the "capability":

-        the "capability" from NSFs and

-        the "capability" from controller (i.e. as the response to Client's inquiry).

I find it not necessary to have the "capability interface" as we already have Client Facing interface and NSF facing interface.

   Capability:  Defines a set of features that are available from a
      managed entity (see also I2NSF Capability). Examples of "managed
      entities" are NSFs and Controllers, where NSF Capabilities and
      Controller Capabilities define functionality of an NSF and about
      Controller, respectively. These functions may, but do not have
      to, be used. All Capabilities are announced through the
      Registration Interface.

Linda

---

From: John Strassner <[email-masked]>
Date: Mon, 12 Sep 2016 17:47:59 -0700

Hi Linda,

>From the Terminology I-D:

Client-Facing Interface:  See Consumer-Facing Interface.
      See also:  Interface, NSF-Facing Interface.

Consumer-Facing Interface:  An Interface dedicated to communication
      with Consumers of NSF data and Services. This is typically
      defined per I2NSF administrative domain.  See also: Interface,
      NSF-Facing Interface.

   NSF-Facing Interface:  An Interface dedicated to communication with
      a set of NSFs. This is typically defined per I2NSF administrative
      domain. See also:  Interface, Consumer-Facing Interface.

Therefore,

   1) I'll bring this up in tomorrow's telecom, but I was pretty sure we had
       previously decided to use **consumer**, not **client**
   2) The point of having a separate Capability Interface is to separate
        actions involving using and manipulating capabilities from other
        actions, such as monitoring. This is because capabilities are
        mechanisms that reflect all or part of the functionality of NSFs.
        As such, they are the building blocks for configuration and
        monitoring; this seemed to me to warrant a separate interface
        for security reasons.

best regards,
John

On Mon, Sep 12, 2016 at 10:27 AM, Linda Dunbar <[email-masked]>
wrote:

> As the I2NSF Terminology has defined two types of the “capability”:
>
> -        the “capability” from NSFs and
>
> -        the “capability” from controller (i.e. as the response to
> Client’s inquiry).
>
>
>
> I find it not necessary to have the “capability interface” as we already
> have Client Facing interface and NSF facing interface.
>
>
>
> *Linda*

-- 
regards,
John

---

From: Annika Sparkles <[email-masked]>
Date: Mon, 12 Sep 2016 20:15:25 -0500

"this seemed to me to warrant a separate interface for security reasons."

If I'm interpreting this correctly, you want to be able to ensure that
capabilities are only shared with consumers of the service on a need to
know basis? Like perhaps in application this would look like an NSF
containing multiple discrete services, with only a select few of that are
allowed to participate in capability discovery and advertisement? I see
your comment coming from a place much like how network engineers disable
LLDP on access ports to reduce leaking information that may help a threat
actor find vulnerabilities in existing code, or map out the network, etc.

Please let me know if my interpretation is correct.

Warmly,

Annika Sparkles

On Mon, Sep 12, 2016 at 7:47 PM, John Strassner <[email-masked]> wrote:

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: John Strassner <[email-masked]>
Date: Mon, 12 Sep 2016 18:38:11 -0700

Hi Annika,

I love your rewording of my comments! Thank you for that.

You are exactly right. My worry is that in I2NSF, capabilities reveal all
or part
of the functionality available. I feel that we need to be careful in
exposing
more than what is necessary at both the consumer and the producer levels.

In other words, I **like** the **principle of least privilege**.

best regards,
John

-- 
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 14:29:10 -0400

John: 

For discussion at the interim:

+1 to John’s belief we agreed upon customer facing rather than client. 

+1 to John’s concept of specifying separate action that use/manipulate capabilities from monitoring functions. 

My comment is practical and design-based. 

Practical: The monitoring and telemetry information is undergoing substantial growth in the IETF standardization, and the industry. It is important to let the capabilities grow separately.  

Design based: These are orthogonal functions.  Why should we mix them? 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Monday, September 12, 2016 8:48 PM
To: Linda Dunbar; John Strassner
Cc: [email-masked]; Diego R. Lopez
Subject: Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

Hi Linda,

Therefore,

        for security reasons.

best regards,

John

On Mon, Sep 12, 2016 at 10:27 AM, Linda Dunbar <[email-masked]> wrote:

-        the “capability” from controller (i.e. as the response to Client’s inquiry). 

I find it not necessary to have the “capability interface” as we already have Client Facing interface and NSF facing interface.

      Registration Interface.

Linda

-- 

regards,

John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 14:37:57 -0400

John and Annika:

+1 on the principle of least privilege.   It is important not to share at the network level (Annika’s LLDP example) what can be used to attack the network. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Monday, September 12, 2016 9:38 PM
To: Annika Sparkles; John Strassner
Cc: [email-masked]; Diego R. Lopez; Linda Dunbar
Subject: Re: [I2nsf] Terminology discussion #2: "capability" & "capability interface"

Hi Annika,

You are exactly right. My worry is that in I2NSF, capabilities reveal all or part

of the functionality available. I feel that we need to be careful in exposing

best regards,

John

On Mon, Sep 12, 2016 at 6:15 PM, Annika Sparkles <[email-masked]> wrote:

If I'm interpreting this correctly, you want to be able to ensure that capabilities are only shared with consumers of the service on a need to know basis? Like perhaps in application this would look like an NSF containing multiple discrete services, with only a select few of that are allowed to participate in capability discovery and advertisement? I see your comment coming from a place much like how network engineers disable LLDP on access ports to reduce leaking information that may help a threat actor find vulnerabilities in existing code, or map out the network, etc.

Warmly,

Annika Sparkles

Hi Linda,

Therefore,

        for security reasons.

best regards,

John

      Registration Interface.

Linda

-- 

regards,

John

-- 

regards,

John

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 11:52:32 -0700

Awesome, thanks Sue!

regards,
John

On Tue, Sep 13, 2016 at 11:29 AM, Susan Hares <[email-masked]> wrote:

> Practical: The monitoring and telemetry information is undergoing
> substantial growth in the IETF standardization, and the industry. It is
> important to let the capabilities grow separately.
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Monday, September 12, 2016 8:48 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* [email-masked]; Diego R. Lopez
> *Subject:* Re: [I2nsf] Terminology discussion #2: "capability" &
> "capability interface"
>
>
>
> Hi Linda,
>
>
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Sep 2016 11:59:11 -0700

And +1 to Sue's excellent example!

On Tue, Sep 13, 2016 at 11:37 AM, Susan Hares <[email-masked]> wrote:

> John and Annika:
>
>
>
> +1 on the principle of least privilege.   It is important not to share at
> the network level (Annika’s LLDP example) what can be used to attack the
> network.
>
>
>
> Sue
>
>
>
> *Sent:* Monday, September 12, 2016 9:38 PM
> *To:* Annika Sparkles; John Strassner
> *Cc:* [email-masked]; Diego R. Lopez; Linda Dunbar

-- 
regards,
John