Subject: [I2nsf] The (in)famous Capability Interface

From: John Strassner <[email-masked]>
Date: Tue, 18 Oct 2016 12:19:26 -0700

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